15:44 < sailus> pinchartl, hverkuil: Ping?
15:45 < hverkuil> sailus: pong
15:45 < sailus> How are you doing? :-)
15:47 < hverkuil> Fine, thanks! You?
15:48 < sailus> Fine, too, thanks!
15:48 < sailus> I wanted to discuss the behaviour of poll on events.
15:49 < pinchartl> sailus: pong
15:49 < sailus> pinchartl: Hi! :-)
15:49 -!- diegoviola [~diego@177.103.105.26] has quit [Ping timeout: 248 seconds]
15:49 < sailus> Currently, if you poll() for something but haven't subscribed for anything, you'll be waiting forever.
15:50 < sailus> That sounds like a silly thing to do, but the issue is more pronounced on multi-threaded applications where one thread does the polling and the other subscribes and unsubscribes the events.
15:51 < sailus> I'm wondering if there is a use case to be able to poll for events but not subscribe for anything right at that time.
15:51 < sailus> If not, I think it should be denied.
15:52 < sailus> What do you think?
15:53 < hverkuil> brb
15:53 < pinchartl> why so ? you can poll with no event subscribed, and get woken up later when the other thread subscribes to an event and the event gets triggered
15:55 < sailus> Yes, you currently _can_ do that, but does it make much sense?
15:55 < sailus> Couldn't you subscribe for the event before polling?
15:56 < sailus> I don't think you can poll for dequeueable buffers if you're not streaming, can you?
15:58 < pinchartl> it might not make much sense, but I don't know if it makes sense to disallow it either
15:59 < sailus> The current behaviour doesn't match that of video buffers. I think it should. Poll-wise the two are analogous.
16:00 < sailus> snawrocki: Ping?
16:00 < pinchartl> does the POSIX standard say anything about a poll() syscall that tries to wait on something that can't happen at the time the syscall is made ?
16:07 < hverkuil> back
16:10 < hverkuil> I don't think it makes any sense to disallow it. You're waiting for an exception. Just because you haven't subscribed to anything doesn't mean you are doing anything wrong.
16:11 < sailus> hverkuil: Do you remember why this was prevented for video buffers then?
16:11 < sailus> I remember there was a discussion on it but I don't remember the particular arguments for or against.
16:11 -!- qbasicer [~qbasicer@198-84-219-216.cpe.teksavvy.com] has quit [Quit: No Ping reply in 180 seconds.]
16:11 -!- qbasicer [~qbasicer@198-84-219-216.cpe.teksavvy.com] has joined #v4l
16:12 < hverkuil> More importantly: a select() call can wait for exceptions on multiple filehandles, and it is perfectly fine to wait for one that cannot - at the moment - produce an exception.
16:13 < sailus> The same is true for video buffers also. :-)
16:14 < hverkuil> With regards to polling for read/write: nobody really knows what to do there. For the most part it is just a copy of what we did in the past.
16:14 -!- smartin_ [~smartin@20-87-190-109.dsl.ovh.fr] has joined #v4l
16:15 -!- smartin [~smartin@20-87-190-109.dsl.ovh.fr] has quit [Ping timeout: 264 seconds]
16:15 < sailus> The practical problem of this is that if a control thread unsubscribes an event, another thread polling the events will wait forever, unless special care is taken to prevent it from doing that, e.g. by sending it a signal.
16:15 < hverkuil> Basically poll returns an error (looking in videobuf2-core.c here) if it has to start the DMA engine and that fails (I think that makes sense), and if you poll and there are no buffers queued (I always thought that was a bit fishy).
16:17 < hverkuil> A possible solution might be to have unsubscribe signal anyone listening to that event.
16:18 < hverkuil> I haven't really thought about how that should be implemented, but that's an exercise for the reader :-)
16:19 < sailus> Should there be event unsubscription events? :-)
16:19 < sailus> That'd solve the issue in a way.
16:20 < hverkuil> or perhaps just wake up any subscribers without actually creating an event in the event queue.
16:22 < sailus> That's one way, too, but how does a subscriber then know that it got waken up because there are no events subscribed?
16:23 < sailus> This also wouldn't help those calling VIDIOC_DQEVENT directly (unless an error was returned).
16:23 < pinchartl> sailus: what does your poll thread need to do when no event is subscribed to ?
16:23 < hverkuil> Well, the control loop still needs to tell the poll loop that it should stop polling for that filehandle. You still need that, otherwise the poll loop would just, well, loop.
16:24 -!- tusharb [~tusharbeh@115.113.119.130] has quit [Excess Flood]
16:25 -!- tusharb [~tusharbeh@115.113.119.130] has joined #v4l
16:25 < sailus> pinchartl: I think it'd just quit.
16:26 < pinchartl> so basically you have an event poll thread that processes events, and at clean up time another thread unsubscribes from all events ?
16:26 < pinchartl> and you want your polling thread to finish then ?
16:27 < sailus> The polling thread might do something else as well, but I don't think it matters much here.
16:27 < sailus> Yes --- I think the control thread could tell the polling thread to stop polling for events through a different mechanism, it doesn't have to be over the V4L2 interface.
16:28 < hverkuil> I think it makes sense that when you unsubscribe to an event, anyone listening to it should be woken up. But other than that I think it is an application issue.
16:31 < pinchartl> your control thread can communicate with the polling thread using a pipe for instance
16:31 < pinchartl> you could then poll() on the pipe as well
16:33 < sailus> pinchartl: Interesting idea.
16:38 < sailus> I think that could even be a much better option.
16:42 < sailus> I'm also not sure if it'd be feasible to just tell once about the unsubscription to everyone who subscribed it: subscriptions are by file handle, not by thread.