[linux-audio-dev] deblocking snd_seq_event_input()

[Paul Davis]

>The ideal solution for me would be that closing the sequencer handle
>would make the snd_seq_event_input() return with an error.

if it doesn't then it seems to me that there is an error in alsalib or
alsa-kernel. i hadn't realized that you were actually closing it - my
understanding was that you just wanted a way to get the poll-ing
thread to return.

>For inter-thread communication I don't use poll() or any other
>fd based systems either, as they are quite heavy.

until futexes came along, they were the fastest thing in town.

pthread condition variables look cheap until you get "under the hood"
to see how they are implemented. in linuxthreads, they used kill(2),
which is massively slower than using poll/select.

i agree that with the advent of futexes, poll is no longer ideal,
however ...

unix in general continues to suffer from the lack of a generalized
"block until <something> happens" call, where <something> can be a
change in the state of a file descriptor, a POSIX signal (including
SIGALRM/setitimer timers), a fixed interval of time, a semaphore, a
sysv msgqueue, or any other model of "block-waiting" event.

as a result, if you need to wait for 2 or more kinds of conditions
(e.g. file i/o readiness changes *and* a request from another thread),
then you have to pick one API and squeeze at least one of the
conditions into it (as libclthreads does). this situation is
despicable and ugly, but i suspect it will never be fixed.

--p