[linux-dvb] Re: blocking FE_SET_FRONTEND ioctl in non-blocking mode

[Johannes Stezenbach <js@convergence.de>]

Ragnar Sundblad wrote:
> 
> --On den 11 maj 2004 23:53 +0100 Andrew de Quincey <adq_dvb@lidskialf.net> 
> wrote:
> 
> >However, looking back at it, I don't know if this is a good idea: (a) it
> >has  the nonblocking blocking issue, and (b) a multithreaded app might
> >have  different threads for tuning and for receiving data, in which case
> >the  getting-old-TS-data problem would still occur.
> >
> >Anyone have an opinion on whether I should remove it?
> 
> It sounds that this fix is trying to work around bugs in
> userland software. If so, I'd say lets fix the user land
> software instead, and remove the fix (at least some time later,
> and maybe file a bug).

Full ACK. The frontend API is specified to be asynchronous, if
userland sets filters before the frontend reports successful
tuning it's its own fault.

IMHO the code must be removed, because some software relies
on the non-blocking behaviour of FE_SET_FRONTEND.

> If the fix also has something to do with the hw_sections=0 bug
> (<http://www.linuxtv.org/mailinglists/linux-dvb/2003/06-2003/msg00626.html>
> , 
> <http://www.linuxtv.org/mailinglists/linux-dvb/2003/06-2003/msg00639.html>)
> I think that you should leave it in.

That's the wrong way to fix it, then.

IIRC I got stale data in manual testing with szap and test_sections,
which indicated something like a missing ringbuffer flush.

Johannes


-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.