On Mar 28, 2010, at 04:27, Markus Humm wrote: > I never really understood why OnDataAvailable isn't called in a way > which hinders such reetrancy problems. Isn't the Windows message which > triggered it taken off the message queue by then? If not, why not?
The problem is that it is not just a message that triggers it: it is called from various places in response to some conditions. In this case, it is called from ASyncReceive when data arrives, and as a last resort when closing the session (either after a normal close or abort), when the Receive Buffer is dirty. The re-entrancy occurs because the Receive Buffer is not cleared until later in ASyncReceive, but ASyncReceive will exit early if TriggerDataAvailable failed with an exception. Therefore even though the application may have handled the event and received the buffer before failing, the event may be triggered again when closing the session because the Receive Buffer is still marked as dirty. To compound this, ASyncReceive swallows all exceptions, so the application will act weirdly but never notice. As I said in my previous message, the solution to this right now is to handle *ALL* errors in OnDataAvailable, and not call Abort during it. I believe I solved this in my Send-Mail Queue Server by posting a Windows message to my working thread and calling Abort outside the context of the OnDataAvailable event. This seems to be the safest route. As far as I can tell, OnDataAvailable is not triggered via Windows message, but by direct call from various methods. Perhaps this should change? However, since it needs to be called as a last resort before closing, a Windows message may never arrive if we are destroying the component. dZ. -- DZ-Jay [TeamICS] http://www.overbyte.be/eng/overbyte/teamics.html -- To unsubscribe or change your settings for TWSocket mailing list please goto http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be