> > Huh? It's not that hard of a problem. You have one (or several) thread
> > that just reads from network sockets. They package up the requests and put
> > them on the end of a queue. The other threads just pull requests off the
> > head of the queue. The trick is all in waking up the sleeping threads when
> > the queue becomes non-empty without having the "thundering herd" problem.
>
> 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.
The Roxen webserver (www.roxen.com) in multithreaded mode works
(almost) like this: it has a request accepting and data shuffling thread
(select()/poll()-based) and a pool of "request handling" threads, with a
requests queue inbetween.
It also has a single-thread mode where the data shuffler does the
actual work too.
A third mode (Accept And Parse) is being deeveloped. It uses lightweight
threads (and sendfile()) for even better performance.
-- Kinkie primary e-mail: kinkie@kame.usr.dsi.unimi.it[random fortune] You are fairminded, just and loving.
- 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/