Tim Goetze wrote:
>
> Today Abramo Bagnara wrote:
>
> >Paul Davis wrote:
> >>
> >> >Don't make this mistake: poll *have* to return immediately in *all*
> >> >cases where to wait is useless (i.e. when no non-user driven event may
> >> >happen).
> >> >
> >> >This is the rule you need to remember.
> >>
> >> where does this rule come from? i was under the impression that
> >> poll(2) should timeout in those cases, not return immediately.
> >
> >Common sense I'd say ;-) Why to wait for events that cannot happens?
> >
> >The "Waiting for Godot" approach seems not sensible in CS.
>
> well, if there are > 2 threads, one only polling and others doing
> management work -- and this is probably the most useful approach to low-
> latency PCM IO -- it is imaginable that a non-polling thread starts and
> stops the device.
In this case pthread_cond_wait and pthread_cond_signal is a better
approach, I think...
> so in this case, the POLL{IN|OUT} events _can_ happen without the
> device being started when poll() was called, right?
>
> i'd like to throw in that multithreaded common-sense differs greatly from
> common common-sense ;)
Take it in another way: if you expect to have a PCM in regular state and
then call poll, but before the call an xrun happened, you keep your
application waiting forever.
--
Abramo Bagnara mailto:[EMAIL PROTECTED]
Opera Unica Phone: +39.546.656023
Via Emilia Interna, 140
48014 Castel Bolognese (RA) - Italy
ALSA project http://www.alsa-project.org
It sounds good!
_______________________________________________
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
