there are four things that really suck about sigio.
in order of most-significant-suckage to least-significant-suckage, i see
them as:
[1] signals are very heavy.
thousands of signals/second does not scale on SMP due to the
serialization of them in the kernel.
(just look at the code path for delivering a signal)
signals also resulted in 128 u32's being transferred from kernel
to userspace for every signal. thats a lot of memory i/o
bandwidth consumed at 1000's of concurrent sockets
and tens-of-thousands of events/sec happening.
[2] SIGIO only exposes half of the POLL_OUT semantics.
with poll(), you can use POLL_OUT to indicate if there
is free buffer space to write into or not.
with SIGIO, for most applications, you can only find out
by issuing a write() and get back a -EWOULDBLOCK.
to indicate !POLL_OUT.
(perhaps that has been addressed in the last 12 months or so;
but i doubt it)
[3] SIGIO had no easy recovery path if you hit the maximum-
queue-limit for number of signals queued to userspace.
(ok, you *could* do a poll() and start again, but it couldn't
be done in a 100% race-free manner)
[4] you couldn't enable SIGIO on a incoming socket
accept()ed without there being a race window where
something happened to that socket between accept() and
enable-SIGIO. [sort-of related to (3); you could work-around
it by doing a poll() on the socket after enable-SIGIO, but
it makes a clean interface a horrible interface]
other miscellaneous things that makes SIGIO less usable in the real-world:
- you can only get one event at a time -- that means tens-of-thousands
to hundreds-of-thousands of system calls / second just to get event
status, when it'd probably make more sense to poll for multiple signals
at the same time
- SIGIO only addressed "event notification". it did nothing to address the
other large scalability that you typically hit when writing
high-performance i/o
systems: overhead of memory-copy from userspace<->kernelspace.
various zerocopy mechanisms help address that side of thing, but if you're
comparing aio to SIGIO, aio *is* addressing a much larger problem than just
SIGIO on its own
cheers,
lincoln.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/