Date: Tue, 24 Apr 2001 20:25:35 -0500 From: Mike Meyer <mwm@mired.org> To: "Hervey Wilson" <herveyw@dynamic-cast.com> Cc: "Mark Giglio" <markgiglio@yahoo.com>, <questions@FreeBSD.ORG> Subject: Re: hotmail converted from freeBSD Message-ID: <15078.10127.320036.450249@guru.mired.org> In-Reply-To: <007101c0cd1f$8d8afbb0$0101a8c0@chillipepper> References: <15077.62126.88738.629586@guru.mired.org> <000d01c0cd1a$83109640$0101a8c0@chillipepper> <15078.6283.75950.909160@guru.mired.org> <007101c0cd1f$8d8afbb0$0101a8c0@chillipepper>
next in thread | previous in thread | raw e-mail | index | archive | help
Hervey Wilson <herveyw@dynamic-cast.com> types: > From: "Mike Meyer" <mwm@mired.org> > > Hervey Wilson <herveyw@dynamic-cast.com> types: > > > Developing a full-blown web server on Win9x wouldn't be a Good Thing > (TM). > > > The "thread per socket" model is not the recommended solution for > Windows > > > 2000 (see below). IIS does not use that model. > > [...] > > > Windows 2000 has an asynchronous IO subsystem that supports a model > where a > > > pool of threads can wait on completion objects and the operating system > > > wakes threads as required to handle IO events. This is typically a more > > > scalable than the "thread per socket" model although it not for the > faint > > > hearted developer ;) > > This sounds like a the "thread per socket" model generalized so that > > you have multiple threads waiting on one socket. Which leads to the > > question - where's the context for the socket go? I.e. - if I've > > processed the header of an HTTP request and am waiting on the data in > > the request to be available, where does the context information get > > stored? > You can associate a per-file handle completion key with a completion port > when you add the file handle to the port (note that socket handles are > treated as file handles). When a completion port is signalled you can > retrieve the completion key. So it's a matter of creating a hashtable (or > other) data structure that maps the completion key to your context > information. This sounds like a "worst of both worlds" approach. You've got the context switches and threading problems (as you mention, not for the faint of heart) of the thread per socket approach, along with the problems of sorting out the context that come with the single thread w/select model. Does it really save anything besides the memory overhead of the threads you need for each socket? Maybe I should just ask for a pointer to a white paper on the subject. > > > Which leads me to ask a question: where can I find more information > about > > > thread models for FreeBSD ? > > -stable gives you posix threads, and you start with the pthread manual > > page for information on that. -current is in the midst of rearranging > > all this, and you need to follow the appropriate developer mail lists > > for information on that, though the API will continue to be posix > > threads. > Thanks. I know Linux doesn't have native kernel threads, does FreeBSD in > either -stable or -current ? -stable no, -current yes. Last time I looked - months ago - they were still converting various things to kernel threads and working on removing the giant lock that -stable uses. <mike -- Mike Meyer <mwm@mired.org> http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-questions" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15078.10127.320036.450249>