If you go to the online version: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/h tml/frlrfsystemnetsocketssocketclassbeginreceivetopic.asp
there's a link down the bottom of the page where you can send them comments on the subject. It's slightly bizarre that the comment is in there. I think it may well be an accurate description of how it works when you don't have IO completion ports (e.g. on Win9x). But it's a description that doesn't need to be in there at all - why would I care what it does with threads internally? It feels like it's been written out of order - threads need to be mentioned because you need to know you'll be called back on a different thread from the one you started the operation on. But that sentence really doesn't get it across well. Actually the whole paragraph seems whacky. It also tells you that your callback method should implement the EndReceive method. Last time I checked Microsoft had already implemented it for us, and all we have to do is call it... In fact now that I read the whole description through, I get the impression that it was written by someone who didn't quite get delegates, asynchronous execution, threading or IO completion ports... -- Ian Griffiths DevelopMentor > -----Original Message----- > From: John Davis [mailto:[EMAIL PROTECTED] > > So who do we write to tell them to correct the documentation? > > ----- Original Message ----- > From: "Griffiths, Ian" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Wednesday, August 20, 2003 7:37 AM > Subject: Re: [ADVANCED-DOTNET] Asynch sockets and IO completion ports > > > Assuming you only call EndReceive after you've got the callback, yes, > nothing should need to block on EndReceive. Your code won't block > because the callback only happens once there is data to retrieve. And > there won't be any thread blocked inside the CLR just to service your > particular receive request because it'll be handled by the pool of > threads dedicated to async IO requests, if the OS supports IO completion > ports. > > > -- > Ian Griffiths > DevelopMentor > > > -----Original Message----- > > From: John Davis [mailto:[EMAIL PROTECTED] > > > > Someone pointed this out to me the other day in the docs ... > > When your application calls BeginReceive, the system will use a > separate > > thread to execute the specified callback method, and will block on > > EndReceive until the Socket reads data or throws an exception. > > > > I would hope that the callback doesn't get fired until after the > requisite > > bytes have been read into the receive buffer. ie Right after > > GetQueuedCompetionStatus has indicated this IO op has completed. So, > on > > an OS that supports IO completion ports, there should be no blocking > with > > EndReceive. > > > > Right? > > =================================== > This list is hosted by DevelopMentor(r) http://www.develop.com > NEW! ASP.NET courses you may be interested in: > > 2 Days of ASP.NET, 29 Sept 2003, in Redmond > http://www.develop.com/courses/2daspdotnet > > Guerrilla ASP.NET, 13 Oct 2003, in Boston > http://www.develop.com/courses/gaspdotnet > > View archives and manage your subscription(s) at > http://discuss.develop.com > > =================================== > This list is hosted by DevelopMentor(r) http://www.develop.com > NEW! ASP.NET courses you may be interested in: > > 2 Days of ASP.NET, 29 Sept 2003, in Redmond > http://www.develop.com/courses/2daspdotnet > > Guerrilla ASP.NET, 13 Oct 2003, in Boston > http://www.develop.com/courses/gaspdotnet > > View archives and manage your subscription(s) at > http://discuss.develop.com =================================== This list is hosted by DevelopMentorŪ http://www.develop.com NEW! ASP.NET courses you may be interested in: 2 Days of ASP.NET, 29 Sept 2003, in Redmond http://www.develop.com/courses/2daspdotnet Guerrilla ASP.NET, 13 Oct 2003, in Boston http://www.develop.com/courses/gaspdotnet View archives and manage your subscription(s) at http://discuss.develop.com
