Messages in this thread | | | Date | Tue, 27 Apr 1999 09:41:04 +0200 (CEST) | From | Francesco Chemolli <> | Subject | Re: OT: multithreaded web server implementation (Re: Linus on Linux, Apache and Threads) |
| |
On Sat, 24 Apr 1999, Olaf Titz wrote:
> > 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/
| |