On 2/17/06, Joseph J. Strout <[EMAIL PROTECTED]> wrote: > >The bug appears to be in the socket event handling code: It allows new > >incoming socket events to be processed immediately instead of putting > >them into a queue and handling them only if previous socket events > >have been handled. > > Only if the new event is Error. > > >I wonder if Aaron, who would probably be responsible for this, even > >agrees that this is a bug? > > If you're seeing it with anything but Error, it would be. With > Error, it is not.
OK, since everyone that works at RS (or used to) is so certain that there's no re-entry unless it's an Error, I'll not keep questioning that for now unless I can prove it. But let's go back to the Error handling then. While I agree that it's necessary that an Error condition must be signalled ASAP, it's still not right to interrupt the current handler in the middle of what it's processing. After all, the data that event is processing, arrived already WITHOUT error, right? The Error condition came later. What should be done is that the Error event only gets inserted to the_front_ of the queue so that if that current handler is _finished_, the Error event gets invoked instead of other pending data handlers. If find this necessary because otherwise we as programmers have to deal with a situation we're usually not prepared for: Since we may not be using threads, there should be no need for us to think of concurrency issues such as which can happen when accessing shared resources (i.e. properties) from concurrent threads. But the current behaviour introduces this complication for us ordinary non-thread users now, doesn't it? And that's scary, because I might have code in my socket handlers that might change a few global states in one of its handler, and if it gets interrupted in the middle of it, this might lead to bad states making my entire program fail (lock up, assert error, etc.). You know what I mean. The problem is that the Error condition is something we usually, when all works, would not be happening, and is therefore hard for us to see in testing. So, we'd see our program rather RANDOMLY fail out in the field with users and we'd have NO idea why, because most of us would not even think of the possibility of this reentry, because that's not what usually happens in RB! So, the current behaviour introduces an ugly, hard-to-debug, situation. The work-around, which is to queue Error events into the head of the line would be the saef solution while not really causing problems, because the to-be-interrupted data handler should not suffer from that, or would it? After all, that's the behavior _I_ would expect and that how I'd write my code: That every handler is an entity in itself and that AFTER it an Error might tell my program that I can discard what I just got thru a data handler. Logical, isn't it? -- Thomas Tempelmann - exaggerating over a million times a day! http://www.tempel.org/rb/ -- The primary source of outdated REALbasic plugins and examples Skype: tempel.org AIM: superTempel _______________________________________________ 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>
