[lkml]   [2001]   [Dec]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: 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

    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
    - 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.


    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,

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:14    [W:0.026 / U:58.408 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site