From owner-freebsd-chat Thu Apr 26 8:27:59 2001 Delivered-To: freebsd-chat@freebsd.org Received: from guru.mired.org (okc-65-26-235-186.mmcable.com [65.26.235.186]) by hub.freebsd.org (Postfix) with SMTP id 11B6437B423 for ; Thu, 26 Apr 2001 08:27:55 -0700 (PDT) (envelope-from mwm@mired.org) Received: (qmail 7653 invoked by uid 100); 26 Apr 2001 15:27:52 -0000 From: Mike Meyer MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15080.15992.732520.463161@guru.mired.org> Date: Thu, 26 Apr 2001 10:27:52 -0500 To: "Hervey Wilson" Cc: "Mark Giglio" , Subject: Re: hotmail converted from freeBSD 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> X-Mailer: VM 6.90 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG% *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\ Sender: owner-freebsd-chat@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [Moved from -questions to -chat] Hervey Wilson types: > From: "Mike Meyer" > > > > 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, 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