lkml.org 
[lkml]   [1998]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Thread implementations...
    Gerard Roudier writes:
    >
    > On Tue, 23 Jun 1998, Richard Gooch wrote:
    >
    > > Well, I'm not one to jump to using threads just for the hell of
    > > it. Why not read the proposal carefully before jumping up and saying a
    > > threads-based solution is flawed? See:
    > > http://www.atnf.csiro.au/~rgooch/linux/docs/io-events.html
    >
    > I did read your proposal. As answer, here is the description of an
    > application program I wrote 5 years ago and that is always alive
    > nowadays.
    >
    > - Completely even driven.
    > - Use SIGIO under UNIX.
    > - Use non-blocking mode under UNIX.
    > - Use select and perform select for write only for socket on which send
    > returned EWOULDBLOCK on UNIX.
    > - Implement both the client side and the server side of a sophisticated
    > protocol.
    > - 1 process is able to handle severall hundreds connections at the same
    > time, client and server as well.
    > - Nominal load 100 to 200 simultaneous connections.

    So when you want to know that a connection has fresh incoming data,
    you get SIGIO when the event comes? Now how do you know *which* FD
    received new data? AFAIK the signal handler has no knowledge of which
    FD had the I/O completed. It looks to me you are then forced to
    attempt a read on *every* FD.

    How on earth does this scale with large numbers of FDs?

    > Use threads for this kind of applications and you break portability and
    > probably performances at the same time.

    Portability:
    #ifdef _POSIX_THREADS
    do it with threads and get good scalability ();
    #else
    do it with poll(2) and hope for the best
    #endif

    Performance: unless you have some secret way of finding out *which* FD
    received data, your scheme is far slower than a simple poll(2)
    implementation. And I think that my threads-based approach will work
    well. I'll be publishing numbers too.

    > Using 1 process with bunches of threads is the common way to develop
    > optimized application for NT. Doing so, you run the risk to break
    > performances and portability to other O/Ses.
    > My experience is that a well designed application can be ported to
    > NT/95 and often OS2 and that applications that have been developed
    > for these crap platforms are about not portable to other platforms.
    >
    > Having nice thread implementation on UNIX in order to use them
    > intelligently is OK. But if the goal is to follow Microsoft
    > dictatorship in order to facilitate port of NT applications
    > to UNIX, them my feeling is that we are just ripped off.

    No, I'm proposing a pure-UNIX solution for UNIX systems, for maximum
    portability. On a system without thread support, you fall back to
    simple poll(2) because that's all you can do.

    > Your proposal is to divide the whole FD list to select()/poll()
    > into severall ones, each handled by 1 thread.

    Yes. Just two threads. One for the active list and the other for the
    inactive list.

    > You are exchanging CPU load due to FDs list scan for context-switching.
    > This can be an interesting optimization for some specific
    > applications. For some other, this probably will make no
    > differences or perhaps have adverse effects, in my opinion.

    I don't think there will be that much context switching going on that
    it becomes an overhead. Anyway, we'll see.

    Regards,

    Richard....

    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.rutgers.edu

    \
     
     \ /
      Last update: 2005-03-22 13:43    [W:0.022 / U:92.652 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site