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?),
etc.
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.
Olaf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/