On Mar 27, 2010, at 13:21, wilfried Mestdagh wrote:
> These are possible untested situations. It is possible to call Abort from
> within an event, but why should you call Abort if the session is closed?
I think that he means that if there is an exception in the OnDataAvailable
handler, and you trap it and call Abort(); then, since the OnDataAvailable
event hasn't completed and returned normally, OnDataAvailable will be called
again.
The order of events is like this (simplified):
1. Data arrives and WinProc message manifold will call ASyncReceive.
2. ASyncReceive triggers OnDataAvailable so that application may retrieve
buffer.
3. Application handles OnDataAvailable but causes exception within the handler.
This is the application's fault.
4. Exception is trapped by ASyncReceive.
5a. TWSocket bug: exception is ignored by exception handler, and ASyncReceive
exits normally.
* This is bad because the application is now in an unstable state with an
unhandled exception that it never knew about.
5b. TWSocket Modification suggested by Jon Robertson and I: instead of
ignoring exception, trigger OnBgException to give a chance to the application
to deal with it.
6. The OnBgException trigger will either call Abort() if the handler sets a
flag, or it will raise an exception otherwise. The default is to raise an
exception.
Either way there is a problem:
* If Abort() is called, since OnDataAvailable never finished, the buffer is not
marked as read, and the event will be called again when the session is closed!
* If an exception is raised, it will be bubbled up to the custom WinProc, which
will call OnBgException again!
Obviously, triggering OnBgException from ASyncReceive (5b above) is a Bad Idea.
But the current way (5a above) will ignore errors which put the application in
an unstable state.
I do not have a solution right now.
dZ.
--
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
