[linux-audio-dev] realtimeness: pthread_cond_signal vs. pipe write

[Tim Goetze]

[Paul Davis]

>On Wed, 2006-06-07 at 11:12 +0300, Jussi Laako wrote:
>> Paul Davis wrote:
>> > writing to a pipe is not 100% RT safe, but if the pipe is created in a
>> > shm filesystem, its as close to it as you will get without ... 
>> 
>> Nowadays, there's also available a very good interface from POSIX RT
>> extensions; posix message queues. See mq_send(3). You can use either
>> mq_receive(3) or mq_notify(3) for reception of the message.
>> 
>> I also measured posix message queues to be about twice as fast as for
>> example local (unix) sockets.
>> 
>> Now that Linux systems generally are pretty close to full POSIX
>> (IEEE-1003.1) compliance, I don't see any reason why not to make
>> advantage of it.
>
>nice to hear that they are faster. on the other hand, once again POSIX
>screws us all over by not integrating everything into a single blocking
>wait call. i've said it before, i'll say it again - this is one of the
>few things that the win32 API gets right - you can block in one call on
>almost *anything*. AFAICT, you cannot select/poll on a msg queue.

actually, according to my copy of 

/usr/src/linux/ipc/mqueue.c 

and

http://laurel.datsi.fi.upm.es/web/cgi-bin/man/man2html?7+mq_overview

linux takes us out of the posix stone age and implements the poll 
syscall on message queues (which are simple file descriptors to a
linux application). thanks kernel guys!

portability questions aside, it remains the question whether mqd_t is 
significantly faster than an ordinary pipe when used with poll().

cheers, tim