Joseph J. Strout wrote:
At 11:20 AM -0500 2/17/06, jon pipitone wrote:
Okay, so I'm left in a similar situation I was in before. How should I
cope with the possibility of the Error event being called whilst I'm in
the middle of handling some other socket event?
Well, to answer that, we'd first need to know why it's a problem. Why is
it a problem?
But all of this seems like I'm really having to work around the (what
I'd say is) faulty behaviour of the socket class. If the goal of having
the Error event fire as a background task is so that my "code can
realize that the socket is pretty much worthless at that point" then
some rethinking needs to be done. Why? Because once the error event has
completed the event it overlapped continues where it was interrupted and
so doesn't "realize" anything.
Only if you've programmed it that way. If the other event needs to know
when an error has occurred, then presumably you have some property you
set in the error event, and check this in your other events.
No no no. Even if I set some property in the overlapping error event
the code in my other event would still have to know to check this
property. The problem is that nothing can be communicated from the
overlapping Error event to whatever event is overlapped unless that
other event is already programmed to constantly check this error flag.
But then:
I mean, if it's critical to realize the state of the socket we
already have the tools with the LastErrorCode and IsConnected methods.
We already have exactly these properties we can use to determine if the
socket is still connected or not. Presumably if all the Error event is
fired for is so that we can set some flag saying "this socket is
worthless" well then we already get this information with the
LastErrorCode and IsConnected values. The event might as well not fire
but just update the built-in flags.
That said, I think Thomas has hit it on the nose when he talks about
interrupting Error event causing more problems than it solves. We can't
do anything in the Error event that changes state in any other part of
the application because the other parts don't expect this to happen, and
*can't* expect it to happen because we're in a single thread so none of
the concurrency management tricks, like CriticalSection, work.
Moreover, because it fires out of sequence we're actually forced to
check whether the socket has an error, rather than rely on being
notified by the Error event.
We're left with an impotent and bug-causing event which we have to work
around by either putting disableBackgroundTasks everwhere (nasty) or by
writing a socket subclass that propery queues up the events (less nasty,
but still nasty).
Gosh, I feel like I'm ranting a bit, sorry for that. In any case it
should be clear by now what my problem is with this. Since I had
assumed the Error event fired in sequence I was putting cleanup code and
other things which change the state of the application which cause the
overlapped event to raise runtime exceptions or give the user odd
feedback, etc..
jp
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
