[linux-audio-dev] FIFOs vs. sockets

Paul Davis paul at linuxaudiosystems.com
Fri May 16 07:54:00 UTC 2003

>> for communication that can wake another thread/process, shared memory
>> is not an option: there is no way to "wait" on shared memory. for
>> that, a pipe is notably faster than a tcp socket and a bit faster than
>> a unix socket. for actual data movement, shared memory beats
>> everything hands down since its zero copy.
>> linux pipes are about the fast IPC on any operating system so far,
>> although i have heard good things about futexes in kernel 2.5/2.6.
>Has anyone tried using realtime signals instead of a pipe for this?

there seem to be mixed reports on the implementation of rtsigs in the
kernel. i've seen stories from some people saying they don't work,
and/or they don't work correctly.

anyway, they are inherently slower than a pipe, because the pipe model
doesn't require creation and use of a signal handling stack for the
task. the task is already blocked, and you just wake it up. with any
signal (including an rtsignal) you have to setup the signal call
stack first. 

there is still, as i've mentioned before and as someone even posted a
kernel patch (here) for, the idea of pipes that are not protected by
fs locks, which would speed them up even more.

More information about the Linux-audio-dev mailing list