Re: [linux-audio-dev] deblocking snd_seq_event_input()

On Mon, May 09, 2005 at 06:56:26AM -0400, Paul Davis wrote:

> although i use this model as a basic pattern in ardour and other
> software, i think it might be worth asking fons exactly what other
> approaches he can imagine? it appears he might like something along
> the lines of snd_seq_poke(), which would cause the poll on the
> sequencer fd to return with POLLHUP or something related in the event
> set. fons?

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

This not being the case (why not - it's the only sensible thing to
do) the next approach would be sent a dummy event. I'm using the same
method in a 'server' class where a thread is blocked in accept(),
waiting for clients to connect. The only way to get out of the
accept() when you want to close the server is to make a dummy
connection. OTOH, a blocking read() or write() on a socket can
be forced to return by closing the socket in the correct way.

I try to avoid using poll() in multithreaded apps - for me it goes
agains the grain of using separate threads. Either you have just
one, and use poll to wait on a combination of conditions, or you
use a separate thread for each condition, handle as much as you
can locally and then send a messaqge to whoever is interested in
the event. The latter approach leads naturally to clean C++
objects to handle e.g. sockets.

For inter-thread communication I don't use poll() or any other
fd based systems either, as they are quite heavy.
The ITC_ctrl object in libclthreads (used in Aeolus, JAAA and
many other things) provides a thread with 16 message queues,
16 counting semaphores and a timer. A thread can wait on any
combination of these. It uses a single Posix condition variable
(with its associated mutex), is entirely zero-copy, and with NPTL,
very fast. It can also be used in non-blocking modes, e.g. for a
RT audio thread. I'll rewrite it some time to use futexes, and then,
if the ITC_ctrl object and the message objects are in shared memory,
it will even work tranparantly across process boundaries.

-- 
FA