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

["Franck Arnaud" <franck@nenie.org>]

Johannes Stezenbach:

> > I've got a problem with tuning in non-blocking mode:
> > the FE_SET_FRONTEND ioctl blocks.

> Which frontend driver?

All the frontends I have exhibit the problem:

                    ves1x93  tda1004x grundig_29504-401
FE_GET_INFO         500ms    0ms      0ms
FE_SET_FRONTEND     350ms    5000ms   700ms

It's more dramatic with the TDA1004x, due to firmware loading 
presumably, but all of them are obviously blocking.

Should it be a feature of the frontends anyway? The frontends 
could well be blocking if there's something generic in front 
of them that knows how to fire and queue blocking requests, 
return OK to the ioctl, and then issue a failure event for 
failed requests.

> Anyway, if it only happens once directly after open(),

It happens every time you wake up a card, so it is a show stopper 
for any poll()-based app that closes unused cards -- as it should 
-- and services other things while tuning one card (like another 
card...). I guess I can circumvent it by forking or threads, but 
if it's not fixed it would be more honest to return a "can't do 
non blocking" error on open() with O_NONBLOCK, or if the flag is 
set later. Rereading the API documentation (2.2.1), it seems it
talks about what should happen with blocking mode when opening 
an adapter with several mutually exclusive frontends (someone 
obviously had some specific hardware in mind, in general it 
seems to me you'd want multiple frontends on a single adapter 
to work concurrently) but is not clear about what non-blocking
means for ioctls on a single frontend.




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