[lkml]   [1998]   [Jun]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Thread implementations...

    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:

    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

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

    - 100 to 500 lines of platform specific code per target.
    (Only OS2 port made problems for well known reasons)
    TLI as been one of the target, TANDEM/GUARDIAN too, NT of course,
    and some others.

    (BTW, it is not an X server)

    When this thing looping to himself, it is able to consume 100 % of CPU
    with a low number of context switching.
    On SMP, we can create as much instances of this process as we have CPUs.

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

    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.

    Your proposal is to divide the whole FD list to select()/poll()
    into severall ones, each handled by 1 thread.
    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.


    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to

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