I'm working on a test app now. What I see with Reflector suggests that it unconditionally unpins the send buffer pretty much as the first action within the callback.
It's something to do with exceptions, certainly. In the code that causes it we do a send/receive/shutdown sequence. We also arrange it so that the socket always has a receive outstanding (it's a reusable transport component that we happen to reuse for this client-type activity). Normally there are no exceptions and the callbacks are fine. Whenever we lose a pinned buffer we also get an exception from the (freshly) outstanding receive. It seems there is some sort of race condition between the receive and shutdown calls which has the side-effect that the send callback is 'dropped'. This only happens with a background load on the system so it's a timing (i.e. sequencing) issue. I'm changing the app now to try to log the exact sequence of socket operations in the OK and NOK cases. Of course that will change the timing... I'm pretty sure there's no locking issue here because there are no locks anywhere near this code, there are no hung threads, and the problem highlights the fact that the callback never happens (suggesting it's in the trajectory Win32 -> runtime -> ThreadPool -> System.Net.Socket. Garry. =================================== This list is hosted by DevelopMentorŪ http://www.develop.com Some .NET courses you may be interested in: >>> Error in line 15 of ADVANCED-DOTNET.MAILTPL: unknown formatting command <<< -> .NET Architecture and Design: Designing Distributed Applications with <-
