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

[Jussi Laako]

Paul Davis wrote:
> 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.

POSIX message queues are not very new concept anyway, it dates back to
1993. However, I have to admit that I liked the old QNX concept of
send/receive/reply more.

That's true. On the other hand you can have multiple sending parties on
single queue, so you don't necessarily have to sleep on anything else.
Or you can be signal-like asynchronously woken up when something arrives
on message queue. Imo, generic concept on having to do something like
select/poll on multiple descriptors can be problematic. And you cannot
assign priorities for the descriptor like you can do for messages in
message queue. Most of the real realtime operating systems are
completely based on message queues and message passing.

Message queues need slightly different way of thinking, but on the other
hand, overcome some scheduling related problems when compared to
pipe-like implementations where you don't explicitly specify message
length, nor have priorities.


	- Jussi