I have a issue here that has made me take a closer look at the locking done in the frontend thread, and I've found some suspicious code and an issue needing discussion. First the two suspicious code snippets: 1: In dvb_frontend_add_event e->status is set after the lock is released. This I think can cause dvb_frontend_get_event to return a incomplete/old event. The structure of the ring buffer should remain intact so there is no potential for catastrophic failure. 2: In dvb_frontend_get_event, the code checks if the queue is empty without taking the lock (this itself is ok), and waits if it is. However it does not check again wether there is actually any pending events after taking the lock. This causes a condition so that if several threads are waiting in get_event at the same time many of them can get spurious extra events out (seemingly an entire extra round arount the ring buffer). Still no catastrophic failure that I can think of though. Finally to my actual issue: The events are added to the event queue at the very beginning of swzigzag, and the frontend thread holds fepriv->sem. poll() will immediatly report that new events are available, however calling GET_EVENT on the frontend handle will block untill swzigzag has completed and gives up the lock. Even on non-blocking filehandles. This can for some frontends take very long time and the calling program will just hang, even when using nonblocking io and poll() correctly. Would it be possible to either release the lock and give the ioctl a shot at returning or delay the actual adding of the event till the end of swzigzag? Regards Sigmund Augdal _______________________________________________ linux-dvb mailing list linux-dvb@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
