I would really like to see a test app posted that reproduces this behavior. My best guess is that the problem is due to lack of synchronization somewhere.
"J. Merrill" <[EMAIL PROTECTED]> wrote:I'm surprised that the framework code doesn't allocate a large block of (possibly unmanaged) memory to be used for a pool of send buffers without pinning anything in the managed memory pool. Does what you see with Reflector indicate that it does the unpinning after your callback has returned? If so, perhaps when an exception is raised (and stifled because it's occurring on a thread pool thread) the unpin doesn't happen -- that sounds like a case where an exception handler should be used. It certainly seems like a bug -- something's going wrong that's not your fault... At 07:21 AM 7/26/2004, Garry Barclay wrote >That's not our situation, but it's news to me so I'd like to clarify: If >we create a thread which calls BeginSend sucessfully >(CompletedSynchronously == false) then terminates, then EndSend will >complete indicating a cancellation. I've used completion port before (in >my C++ and Win32 days) and I can't remember coming across this. Moreover, >I can't see why this should be... > >Back to the subject - what we're seeing is a heap which (eventually) >contains about 500 MB of free space. If you dump the heap (using WinDbg >and 'SonofStrike') you see the pattern: > >....etc. > >The IO buffers are each just one or two hundred bytes. Each is kept in >memory by a Pinned GCHandle from an asynchronous Send operation. The >System.Net.Sockets are shutdown an closed and the Socket handles are all >freed. Looking at the framework code with reflector it seems that on >receiving the callback from the OS, the framework should unconditionally >unpin the send buffer before invoking our callback. It's clear that that >isn't happening in this case. > >Garry > >On Mon, 26 Jul 2004 05:22:42 -0500, Mark Smith wrote: > >>Correct. >> >>.NET utilizes the I/O completion port asynchronous socket model >>(WSASend/WSARecv) and therefore has the same restrictions as unmanaged >code >>using that model. One of those restrictions is that the thread initiating >>the socket operation cannot terminate before it is completed or the asynch >>operation is canceled. This is a behavior of I/O completion ports - not >of >>.NET itself. You should still get the callback, but when EndSend is >called, >>it should throw an exception indicating that the operation was canceled. >> >>If you have scenarios where your own threads might exit with pending I/O >>events you will either need to ensure they stick around or post the work >to >>a thread pool (ThreadPool.QueueUserWorkItem) and initiate the BeginSend >from >>there. The CLR will ensure that the thread will stick around in that case >>(it tracks overlapped I/O from the threadpool threads). >> >>Best Regards, >>Mark Smith J. Merrill / Analytical Software Corp =================================== This list is hosted by DevelopMentorŪ http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com =================================== This list is hosted by DevelopMentorŪ http://www.develop.com Some .NET courses you may be interested in: NEW! Guerrilla ASP.NET, 17 May 2004, in Los Angeles http://www.develop.com/courses/gaspdotnetls View archives and manage your subscription(s) at http://discuss.develop.com
