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
