[linux-audio-dev] deblocking snd_seq_event_input()

[Alfons Adriaensen]

On Mon, May 09, 2005 at 10:30:04AM -0400, Paul Davis wrote:

> 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.

The ITC_ctrl thing I use was originally developed under Solaris,
about 8 years ago. Solaris pthreads & friends were comparable to
what NPTL offers now, even then.
 
> i agree that with the advent of futexes, poll is no longer ideal,
> however ...

and the Posix primitives are the winners now.
 
> 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.

Depends. On the best systems, everything - even poll/select - is build
on top of primitives like semaphores and condition variables. I can only
hope Linux will evoluate in that direction too.
 
> 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.

Since I tend to abstract files / sockets / everything that uses fd
into C++ classes, I just give the class its own thread to wait on 
the fd. That invisible (to the class user) 'helper' thread will do
most of the work, and then trigger one of the 32 inputs of the object
owner's ITC_ctrl, which is where the waiting on multiple events is
done. No poll() is ever required.


-- 
FA