16 May
2003
16 May
'03
9:53 a.m.
[...]
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.
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?