lkml.org 
[lkml]   [1999]   [Sep]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: > 15,000 Simultaneous Connections
    Hi,

    On Tue, 14 Sep 1999 23:39:01 -0700 (PDT), Gideon Glass
    <gid@cobaltnet.com> said:

    > I believe that the API presented in the Banga/Mogul/Druschel paper
    > lets you retrieve N events at one time, in order to amortize the cost
    > of the dequeuing operation.

    Fine, I'd be more than happy to see us add a sigwaitinfos() call to
    pass multiple siginfos at once. I'd rather do that than change the
    underlying siginfo mechanism that already exists in Linux.

    > Advantanges over sigwaitinfo():

    > - can dequeue multiple events in one call

    So fix sigwaitinfo, don't redo from scratch.

    > - Queues would be automatically shared -- iff file descriptors are shared.

    Signals can do this in principle. They already do, in fact, but the
    current implementation is too gross --- I don't want to talk about it
    right now. :)

    > - Since there is no implicit per-process state (e.g. signal handlers), we
    > avoid the need for library and application code to fight it out over
    > who gets what signals.

    It doesn't address the underlying issue that *all* of these models
    with explicit event dequeuing rely on a single dequeue call being able
    to handle events from any file descriptor. It's just like select: if
    you have a select loop, then all your libraries need to have
    registered their fds with whatever code is doing the select loop
    (think about the X core event loop, for example).

    With a signal dequeuing mechanism, your application is going to get
    signals destined for various library components if libraries are using
    the same mechanism. Sorry, but there's no magic wand here. In fact,
    the *only* mechanism I've seen which can let a library do its
    event-based work transparently is the signal model: if you want
    non-blocking IO on some set of fds, the library can set up its own
    signal handler for those fds and deal with that signal transparently
    to the rest of the application.

    The event queueing models simply don't have any support for this at
    all.

    Given that the current glibc does have a way to farm out rt signums to
    different components, the argument that completion ports somehow deal
    with libraries better than signals appears to be totally bogus.

    --Stephen

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 13:54    [W:2.705 / U:0.124 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site