What practical risk is there in calling "open" before assigningonreadystatechange callback?

D

David Karr

I'm reviewing some manuscript code that demonstrates a primitive Ajax
implementation. I noticed that the code calls "open()" before it
assigns the "onreadystatechange" callback function. Theoretically, it
seems possible this could be a difficult-to-hit race condition, where
the machinery tries to call the onreadystatechange callback before
it's assigned. The question is, is this really possible in any
existing, even legacy, browser?
 
T

Thomas 'PointedEars' Lahn

David said:
I'm reviewing some manuscript code that demonstrates a primitive Ajax
implementation. I noticed that the code calls "open()" before it
assigns the "onreadystatechange" callback function.

That is usually a good idea because in at least in the Gecko DOM an
xhr.open() call resets the xhr.onreadystatechange property.
Theoretically, it seems possible this could be a difficult-to-hit
race condition, where the machinery tries to call the onreadystatechange
callback before it's assigned.

There is no race condition. Either the assignment took place (which, due to
the observed single-threadedness of all relevant ECMAScript implementations
to date, happens before the open() call), then XHR host object is at least
notified of the property value change; or it didn't take place, then the XHR
object "knows" that the property value "is" still the default (uncallable)
value or the previously assigned callable value.
The question is, is this really possible in any existing, even legacy, browser?

What legacy browsers are you talking about? Anyhow, if that really breaks,
then that browser or rather the XHR implementation it supports is FUBAR.


PointedEars
 
T

Thomas 'PointedEars' Lahn

Thomas said:
David said:
I'm reviewing some manuscript code that demonstrates a primitive Ajax
implementation. I noticed that the code calls "open()" before it
assigns the "onreadystatechange" callback function.

That is usually a good idea because in at least in the Gecko DOM an
xhr.open() call resets the xhr.onreadystatechange property.
Theoretically, it seems possible this could be a difficult-to-hit
race condition, where the machinery tries to call the onreadystatechange
callback before it's assigned.

There is no race condition. Either the assignment took place (which, due to
the observed single-threadedness of all relevant ECMAScript implementations
to date, happens before the open() call), [...]

Err, after the open() call in your case, but before the following statement
is executed. The rest of my statements should hold, though.


PointedEars
 
D

David Mark

I'm reviewing some manuscript code that demonstrates a primitive Ajax
implementation.  I noticed that the code calls "open()" before it
assigns the "onreadystatechange" callback function. Theoretically, it
seems possible this could be a difficult-to-hit race condition, where
the machinery tries to call the onreadystatechange callback before
it's assigned.  The question is, is this really possible in any
existing, even legacy, browser?

What would the open method be racing? Are you thinking of the send
method? Make sure you set onreadystatechange before calling that
method (not only is there a potential race, the send operation may be
synchronous due to protocol, caching or other factors.)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,902
Latest member
Elena68X5

Latest Threads

Top