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