> Richard B. Johnson writes:
> > On Sat, 4 Jan 1997, Richard Gooch wrote:
> >
> > > Richard B. Johnson writes:
> > > > On Fri, 3 Jan 1997, Baldur Norddahl wrote:
> > > > [SNIPPED]
> > > > > On Fri, 3 Jan 1997, Richard B. Johnson wrote:
> > > > [SNIPPED]
> > > > >
> > [SNIPPED]
> > [SNIPPED]
> > > They've learnt that too many processes is a bad thing.
> >
> > They probably have learned nothing.
[SNIPPED]
>
> If you really want the kernel to help in a situation where you have
> 20 000 connections, how about implementing the following:
>
> a system call similar to select(2) or poll(2), except that instead of
> the list of FDs being used for input to the kernel and return from the
> kernel, have the input and return list separate. The return list is
> written in a compact form, such that returned FDs are written in the
> first N entries (where N is the number of returned FDs).
>
> This would have the benefit that the application only has to walk
> through a small list to find FDs which are ready for I/O. Right now,
> the application has no choice but to walk through the entire list of
> descriptors to find which are ready.
> This scheme assumes that only a small fraction of all FDs are ready
> for I/O, which is a fair assumption.
Now you are talking! It appears as though the present method(s) available
for handling multiple clients needs some additional help.
Since "socket()" was a BSD interface. It may be possible to make a Linux
"plugs()" interface that becomes the industry standard for handling multiple
clients in an server environment. The return value from some "wait_for..."
routine returns an index into an array of "client structures" within which
is all the information necessary to perform an immediate function request.
This array of "client structures" contains some members that are never
updated by the kernel, they are used for program specifics, perhaps a
void pointer or two, and a fixed-length block of ints. Ideally, everything
a server could ever do can be deduced from this structure. Note that
double indirection is not very efficient so this structure would probably
be fixed-length (yes, waste some RAM).
>
> Regards,
> Richard....
Cheers,
Dick Johnson
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Richard B. Johnson
Project Engineer
Analogic Corporation
Voice : (508) 977-3000 ext. 3754
Fax : (508) 532-6097
Modem : (508) 977-6870
Ftp : ftp@boneserver.analogic.com
Email : rjohnson@analogic.com, johnson@analogic.com
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.
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-