You don't have to worry.
We keep fooling ourselves, but we have been assured that all browser
implementations of Javascript are single-threaded, non-preemptive.
In other words, although it is event driven, each event runs
consecutively to completion.
On 2006-09-27, at 16:47 EDT, John Sundman wrote:
> 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
