[Grub-develop] A slightly different tack

[Doug S. <dou...@se...>]

I was glancing through the server code.  (Compiles and runs as advertised,
too!)

It looks like CRW will create an IND thread on a per-connection basis, and
when the connection ends, then IND thread ends.

With a lot of connections, that could be a lot of thread
creation/destruction overhead.

I'm just going to toss out the possibility of creating threads on a
functional basis instead of a connection basis.  This model has very light
thread creation/destruction overhead because the threads that process the
connection are created up front (or as needed if the data starts to come in
too fast for the current thread pool to handle).

For example:

Program creates three threads to start with (so there'd be a total of four
initial schedulable units running, the main program and the three threads).

Initial thread #1 (LISTENER) simply listens to for connection requests, and
grants them.  

Initial thread #2 (RECEIVER) listens for data on the incoming connections
and passes it to the rest of the program via either a queue or a SysV IPC
mechanism such as the kernel's message passing feature or shared memory.
It also manages the worker threads (described below), creating them and
removing them as necessary to handle the load.  It is responsible for
maintaining overall connection status.  Overall, though, this thread is
very small and very fast because mostly all it does is get data from the
network and queue it for processing.

Initial thread #3 (WORKER) is the basic worker thread that takes and
processes the data from Thread #2.  It is responsible for maintaining the
state of the client/server protocol as required for processing.  It is not
responsible for any single connection...a single connection is actually
"managed" through a connection state vector (a data structure) that this
thread maintains.  That way, there can be more than one of this kind of
thread, and they are all interchangeable and identical.

Building a server on a functional model like this could eliminate a lot of
complex thread management and is very modular.  I first saw this model used
for an FTP server for Win32.

Comments?  I suppose I can try to code up a quickie skeleton of this
weekend if you would like to see this model in action.

Doug