Date: Tue, 24 Apr 2001 19:00:19 -0700 From: "Hervey Wilson" <herveyw@dynamic-cast.com> To: "Mike Meyer" <mwm@mired.org> Cc: "Mark Giglio" <markgiglio@yahoo.com>, <questions@FreeBSD.ORG> Subject: Re: hotmail converted from freeBSD Message-ID: <001101c0cd2b$7b7c85e0$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> <15078.10127.320036.450249@guru.mired.org>
next in thread | previous in thread | raw e-mail | index | archive | help
From: "Mike Meyer" <mwm@mired.org> <SNIP> > > > 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. > I will try to find a whitepaper for you. One of the best references from a general programming (as opposed to a kernel developers) perspective would probably be one of Jeffrey Richters books (for example "Programming Server-Side Applications for Microsoft Windows 2000". Wrt thread switching, this is minimized in that you can control the number of threads in the pool and the number that are active concurrently and, when a thread finishes a piece of work, the kernel tries to re-dispatch that thread instead of taking a different one off the queue. 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?001101c0cd2b$7b7c85e0$0101a8c0>