At 01:59 PM 20/12/2001 -0800, Linus Torvalds wrote:
>On Thu, 20 Dec 2001, Lincoln Dale wrote:
> >
> > SIGIO sucks in the real-world for a few reasons right now, most of them
> > unrelated to 'sigio' itself:
>
>Well, there _is_ one big one, which definitely is fundamentally related to
>sigio itself:
>
>sigio is an asynchronous event programming model.
>
>And let's face it, asynchronous programming models suck. They inherently
>require that you handle various race conditions etc, and have extra
>locking.
actually, i disagree with your assertion that "asyncronous programming
models suck".
for MANY applications, it doesn't matter. the equivalent to async is to do
either:
- thread-per-connection or process-per-connection (ala apache, sendmail,
inetd-type services, ...)
- a system that blocks -- handles one-connection-at-a-time
the only time async actually starts to matter is if you start to stress the
precipitous performance characteristics associated with thousands of
concurrent tasks in a thread/process-per-connection model. (limited
processor L2 cache size, multiple tasks sharing the same cache-lines
(suboptimal cache colouring), scheduler overhead, wasted
stack-space-per-thread/process, ..).
if you care about that level of performance, then you generally move to an
async model.
moving to an async model doesn't have to be hard -- people generally start
with their own pseudo scheduler and go from there.
"harder" than non-async: yes. but "hard": no.
>SIGIO just isn't very nice. It's useful for some event notification (ie if
>you don't actually _do_ anything in the signal handler), but let's be
>honest: it's an extremely heavy notifier. Something synchronous like
>"poll" or "select" will beat it just about every time (yes, they don't
>scale well, but neither does SIGIO).
actually, my experience (circa 12 months ago) was that they were roughly equal.
poll()'s performance dropped off significantly at a few thousand FDs
whereas sigio's latency just went up.
but it was somewhat trivial to _make_ poll() go faster by being intelligent
about what fd's to poll. simple logic of "if a FD didn't have anything
active, don't poll for it on the next poll() loop" didn't increase the
latency in servicing that FD by any noticable amount but basically triples
the # of FDs one could handle.
cheers,
lincoln.
NB. sounds like you're making a case for the current trend in Java Virtual
Machines insistance on "lots of processes" being a good thing. <grin, duck,
run>
-
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/
This archive was generated by hypermail 2b29 : Sun Dec 23 2001 - 21:00:23 EST