Is there anything in general I should be saying about race conditions
when using our XMLHTTPRequest object?
It seems to me that I see this topic pop up from time to time (with
respect to user code, not VM code), and the very word "asynchronous"
kinda makes one wonder. Yet dthe book "Ajax in Action" by Crane et
al has no index entry for "race condition" either by itself or under
the XMLHTTPRequest object entry.
Does this mean I don't have to worry about discussing race conditions
in the Developer's Guide? Of if I'm wrong about that, how do I
approach this subject?
Thanks,
jrs
On Sep 26, 2006, at 11:25 AM, P T Withington wrote:
> 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
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
