[lkml]   [1997]   [Jan]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: How to increat [sic.] max open files?
    On Fri, 3 Jan 1997, Baldur Norddahl wrote:
    > On Fri, 3 Jan 1997, Richard B. Johnson wrote:
    > > Now, it is not efficient to kick-off a separate child to handle each
    > > connection. It is also not efficient to have a single task handle everything.
    > > There is some design necessary to figure out what goes in between.
    > In the mud case it is actually efficient to keep everything in a single
    > process. At least that is what the profilers say. It is the simulation of
    > the virtual world that hogs the CPU, not the client handling. Having to
    > lock the objects in the virtual world would just complicate the simulation
    > and thereby make it slower.
    > What teoratical background do you have for concluding that using a single
    > process to handle the clients is NEVER efficient?

    The idea is that it is most efficient to have the kernel do as much work
    as possible. The presumption is that the kernel code in any operating system
    will be tuned to perform its function with the minimum possible overhead.
    Indeed, in many architectures, there are even opcodes that are not allowed
    in user-space programs, that are used by the operating system. In fact,
    the operating system can often set some bit in a page-register, rather
    than having to copy data, etc.

    Of course we will always have user-mode programmers who think that they
    can make better code than the kernel code, but you should know how that

    When user code has to keep track of many "sockets" it usually has to look
    through a list (perhaps linked) of things to be done once some event
    (such as an inquiry from a socket-connected client), It can't just use
    socket values as indexes because clients disconnect and new out-of-order
    sockets are assigned for new connections.

    Once the list becomes large, much time is wasted just getting to the
    code that is going to service the request. There might even be a context-
    switch or two before your application actually does anything useful as
    far as the client is concerned.

    Now, suppose your code used a different "port" (after some initial
    negotiation), for each Client. Then suppose your code wasn't even
    executed until the kernel gave you control with the port (read index),
    already found.

    Don't you think that this would be a more efficient way to handle the
    stereotypical Client/Server methodology?

    Now, this is just one example. It is not a good example but it is one
    that is easy to understand. Another example is the simple telnet daemon.
    It issues an "listen", and when a "connect" occurs, it sets up I/O
    descriptors, spawns a child, then goes back to sleep. The child is
    entirely independent "setsid()", uses its own resources, etc. This
    child only worries about one client and has, in fact, become the client.
    Until the number of "connections" reaches some point, this seems very
    efficient. However, memory is being wasted because each of the children
    (now users), have a lot of code that is only used once. At some point,
    having separate children perform tasks on behalf of separate Clients is
    no longer efficient because of the wasted overhead. Note that the telnet
    example could be accessing a database or serving files instead of being
    a terminal server to a shell.

    My theoretical background spans about 30 years, starting as a youngster
    working for Los Alamos Scientific and NASA/Ames up to my present work
    with very high speed data acquisition and number-crunching used in
    3rd generation CAT-Scanners. I have a couple of degrees, but mostly one
    has to learn from the school of hard-knocks when bumping against the
    leading edge of technology.

    Some of this things I say just might be helpful when attempting to make
    some things work a bit better than the general case.

    Dick Johnson
    Richard B. Johnson
    Project Engineer
    Analogic Corporation
    Voice : (508) 977-3000 ext. 3754
    Fax : (508) 532-6097
    Modem : (508) 977-6870
    Ftp :
    Email :,
    Penguin : Linux version 2.1.20 on an i586 machine (66.15 BogoMips).
    Warning : It's hard to remain at the trailing edge of technology.

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