What thread does JavaScript code called from Flash execute on?

Question

As far as I understand, all JavaScript code is event-driven and executes on a single browser thread.

However, I have some JavaScript functions that are called from within a SWF object sitting on the same page. Is this code run in the same manner as regular JS code, or is it on some separate Flash thread?

If it is on a separate thread, can I use setTimeout() to get it to run on the JS events thread? e.g.:

function calledFromFlash() {
    setTimeout(doActualWork, 0);
}

function doActualWork() {
    // blah blah blah
}

Answer 1

It's still on the same thread. However, for most practical purposes if you have such a long-running JavaScript that you're worried your "main" task might block the call from setTimeout, you should consider revisiting your underlying approach.

Update for the bounty:

To expand on the more general question of threading in JavaScript, there is a great discussion with a very revealing answer from Bobince. He cites some very interesting scenarios that might call into question whether we can truly consider JS to be single-threaded, and his conclusion is "not quite".

The conclusion of the comments, which I agree with, is that from the perspective inside the JS runtime, the universe is single-threaded, but because the infrastructure surrounding the JS sandbox is not single-threaded, it can reach inside the sandbox and muck with state in unexpected ways. From inside the runtime, some unknown entity can "suspend the laws of nature" and change things around. But the runtime has no threading construct to handle that scenario natively.

I think the most important way to approach the question is to ask what do we mean by multi-threadedness in a practical scenario? Usually threading issues come down to things like synchronization, which we have to assume the browser vendors have solved for us because again, JavaScript has no native construct for even trying to deal with it ourselves. Hand-wringing about threading does no good without the tools to fix it; no mutexes or locks.

So setting aside those kinds of catastrophic problems, we're down to things like maybe a value gets changed out from under us unexpectedly. But well-written code should be OK with that. Even in Bobince' example, all the code involved is still code that we voluntarily included in the page (even wrote ourselves) so sure, it might be surprising if that code gets fired while your main callstack is ostensibly "blocked". But again speaking to practical problems, what is the worst thing you could do to yourself in that scenario? Nothing too serious.

So that's my long way of saying: I don't know of any documentation from the browser vendors where they say unequivocally whether their JS implementation is single-threaded or not, but I question whether that matters.

Answer 2

Flash ExternalInterface calls are done synchronously using the same processing thread as your main application. Calls from Flash to JS are treated the same as any event binding in your JS application.

I've blogged about using this to your advantage when necessary, though it is more often a hassle.

Here's some other resources referring to this fact: link link link link

I hope that helps clarify things.