On 2006-09-26, at 11:15 EDT, Henry Minsky wrote:
> So, I tracked down the bug that Ben reported in the data loader in
> calendar in DHTML, and I believe this is a pretty clear example of a
> race condition in the interpreter. When you issue an
> XMLHTTPRequest.send() call, a separate thread executes and does
> periodic callbacks to a function that you provide. It looks like those
> callbacks can execute at any point during the main application.
>
> Here's what I saw happening. There is a Laszlo LzHTTPLoader object
> which has a slot named "req" which points to an XMLHTTPRequest object.
> The XMLHTTPRequest object makes periodic callbacks from its own thread
> as the load progresses.
>
> In the callback handler function, I had the following lines in this
> order ('__pthis__' refers
> to the LZX loader class instance)
>
> __pthis__.loadSuccess(__pthis__, lzxdata);
> __pthis__.req = null;
>
> The "loadSuccess" is a hook back to the LFC which fires an 'ondata'
> event in the dataset.
> As it happens, in this application, the "ondata" handler in the
> dataset immediately makes
> another load request . This causes the "req" slot to be bound to a
> new instance of XMLHTTPRequest, and a new load operation is started.
> After that code executes, the
> callback function goes on to the second line, setting "this.req =
> null". Then the first time that the new outstanding XMLHTTPRequest
> thread does it's callback, it finds that slot is null.
> At least I think that is what is happening.
>
> When I reversed these two lines of code
>
> __pthis__.req = null;
> __pthis__.loadSuccess(__pthis__, lzxdata);
>
> Then the bug went away.
>
> So the lesson seems to be that the callbacks from XMLHTTPRequest can
> happen any time and place during execution of the main app code.
The effect you saw is still consistent with non-preemptive run-to-
completion: You said loadSuccess queues the new request, but when
that returns your handler sets the new request to null. So, I don't
think there is any asynchrony here, just a logic error. Even though
these event handlers run to completion, we have to understand that
sending an event may cause arbitrary code to execute. I guess the
non-linearity of event-based code can make it hard to reason about.
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
