Messages in this thread |  | | | Date | Thu, 20 Dec 2001 15:02:10 -0800 | | From | Lincoln Dale <> | | Subject | Re: aio |
| |
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/
|  |