Mailing List archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[linux-dvb] Re: blocking FE_SET_FRONTEND ioctl in non-blocking mode
> I'd say it's a bug.
>
> Which frontend driver?
>
> Anyway, if it only happens once directly after open(), when initializing
> the frontend, I would say it's not worth fixing.
Its _probably_ a piece of extra code I added on purpose, forgetting about
nonblocking mode.
Without the code, the following was happening:
1) Application opens frontend device
2) Application calls FE_SETFRONTEND
3) Application creates a TS filter and starts reading it
4) The frontend tunes the device.
The problem is the device might be already tuned before step 1. In which case,
the application gets some random transport stream data from the previous
attempt, which was very confusing.
The code forces the thread doing the tuning to do:
1) Application opens frontend device
2) Application calls FE_SETFRONTEND
3) The frontend tunes the device.
4) Application creates a TS filter and starts reading it
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?
--
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe linux-dvb" as subject.
Home |
Main Index |
Thread Index