Damien Katz

> I've seen (and even held) my fair share of idiotic programming beliefs based on nothing more than rumor.

Such as......?

Ummm...lessee, oh I know. I once thought I shouldn't learn C++ because all objects didn't derive from a base object. And that's bad, mmmmkay. Fortunately for me, I didn't write a whole article about it.

There are tons more I'm sure, but I can't think of anything interesting right now.

AJAX is threaded from a server connection point of view. They don't mean OS threads. They mean HTTP threads. It makes perfect sense to anyone who knows that a thread doesn't only happen at the OS level, but for ANY asynchronus event.

What does superstition have to do with any of this???

I'm not sure what you are getting at here, but in Web browsers all javascript executes on the same thread and script execution is never interrupted to execute another script event. Yes, HTTP downloads are concurrent (and most likely multi-threaded, but that's not important), and that means that the order in which they complete won't necessarily be the same order they were started.

However, this does not imply multi-threading or a need for mutexes. The script events they fire are handled by a single thread and the currently running script must terminate before another event script is launched.

Also, if the guy can't show a reproducible case, then how can we know for sure the code works at all in the face of actual multi-threading? If we have NO reproducible case (even if it's sporadic, something like the "this code when run 1000 times failed approximately 2% of the time on my machine") then we have no evidence of the implications of javascript multithreading so how can we know the code made things any better?

"You'd think computer programmers wouldn't be superstitious, but I've seen (and even held) my fair share of idiotic programming beliefs based on nothing more than rumor."

That sounds like an introduction to a good article.

I'm confused. Are you saying that the comments by jdodds at the end of the article are incorrect? Specifically:
"Browser JavaScript implementations are single threaded" is, unfortunately, not actually a true statement.

Microsoft Internet Explorer (surprise, surprise) breaks the single threaded JavaScript model. Many of the host objects in IE are implemented as COM objects and Microsoft did not architect the integration in a way that protects the integrity of the JavaScript language. Hence you have issues like closures that capture DOM objects leaking memory. It also means that callbacks into JavaScript from COM objects are usually on a different thread, the thread that's running inside the COM object.

I haven't had to deal with these kind of issues for a while but my possibly faulty recollection is that setTimeout() will perform a thread context switch. So the onreadystatechange handler should not directly operate on a request result but instead should package the result in a closure and then use setTimeout to push processing back onto the primary JavaScript thread.

So the article, while an actual solution, is bulldiculous compared to just using setTimeout to avoid the issue.

Or am I missing something?

grrrr. My comment's blockquote looked right in preview. What's the point of Preview if it posts differently?!?

(I know this is Blogger, not you Damien, but it's a pet peeve of mine when things stage correctly yet break in production.)

John, unless someone can provide proof that any javascript executes concurrently, its simply superstition. The COM objects may be able to post events on another thread, but the browsers script engine will only run them on the primary thread.

I fixed the formatting on your comment. It is caused by a bug in the blogging software (I use MoveableType, not Blogger BTW. Despite this bug in MT, Blogger is far worse IMO)