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

On Mon, May 09, 2005 at 06:56:26AM -0400, Paul Davis wrote: 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