Date: Thu, 26 Apr 2001 10:27:52 -0500 From: Mike Meyer <mwm@mired.org> To: "Hervey Wilson" <herveyw@dynamic-cast.com> Cc: "Mark Giglio" <markgiglio@yahoo.com>, <chat@FreeBSD.ORG> Subject: Re: hotmail converted from freeBSD Message-ID: <15080.15992.732520.463161@guru.mired.org> In-Reply-To: <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> <001101c0cd2b$7b7c85e0$0101a8c0@chillipepper>
next in thread | previous in thread | raw e-mail | index | archive | help
[Moved from -questions to -chat] Hervey Wilson <herveyw@dynamic-cast.com> types: > From: "Mike Meyer" <mwm@mired.org> > > > > 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. > > http://msdn.microsoft.com/library/techart/msdn_scalabil.htm is an old > document written for NT 3.5 that examines some of the scalability issues > when writing server applications for NT. > http://msdn.microsoft.com/library/techart/msdn_servrapp.htm is another older > document that discusses using IO Completion ports with the MFC library (not > my favourite library) but contains discussion of the overall programming > model. http://msdn.microsoft.com/library/periodic/period00/Winsock.htm is a > newer document (last October) that discusses using IO completion ports with > WinSock 2.0. Some of these documents contain pointers to further > information. Unfortunately, none of these are quite as rigorous in their > treatment of the topic as one might hope. Finally, as I mentioned earlier, > Jeff Richter's various books are very good references. Actually, the first one was pretty much what I was looking for - at least at this level. It looks like completion ports give you a way to tune behavior between the single thread w/select and the thread-per-socket model, which is an interesting concept. The real use is to adopt the single thread w/select model to an SMP system. The recommended tuning on a uniprocessor system is a single thread. The only thing that the completion port model clearly saves you compared to the thread-per-socket model is memory resources. It may save you context switches compared to some approaches, but that looks to be more of a problem with the underlying platform than anything else. It does add the problems of dealing with threading to the single thread w/select model. That's pretty much the cost of using more than one CPU, though. In theory, the Unix select & thread semantics can generate this kind of behavior. I'd be surprised if it actually worked that well, though. I'd *not* be surprised if it failed in some strange way. Thanx, <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-chat" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15080.15992.732520.463161>