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 

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-Jay [TeamICS]

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

Reply via email to