Even simpler: put the worker threads themselves on a queue. The
acceptor thread dequeues a worker thread and hands it the request, the
worker threads re-enqueue themselves after doing work. A queue-watcher
thread spawns and enqueues new workers whenever the queue runs dry (or
takes some out of the [end of] a queue when there are too many
unused). A thread can hold a keep-alive connection and not re-enqueue
itself, it can exit (implicitly not re-enqueuing itself) and do
similar stuff it likes, the queue-watcher will always take care. The
acceptor could be split into several threads (easing virtual hosts?),
I expect the queue manager code for this to be very short and
efficient, because it does little more than managing a double headed
linked list and do some wakeup calls.
You can even have multiple queues this way: specialized worker threads
either for request types (file/CGI/servlet/etc) or for virtual hosts.
Would perhaps need some research whether it is better to handle just a
FD or a preparsed request line to the worker threads. In any case,
threads use shared memory, so you don't really pass down the stuff
any sort of pipe.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to firstname.lastname@example.org
Please read the FAQ at http://www.tux.org/lkml/