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.
--
Henry Minsky
Software Architect
[EMAIL PROTECTED]
_______________________________________________
Laszlo-dev mailing list
[email protected]
http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
