Is setTimeout() asynchronous?

[VA]

Suppose I have

setTimeout(foo( ),n);
long_running_fu nction();

Would foo() be executed even when long_running_fu nction() is still
executing? In other words, does the setTimeout() pre-empt anything
else?

[The reason I ask is that I would like to show some feedback to the
user if my long running function takes more than n milliseconds]

Thanks

[Random]

VA wrote:

Suppose I have

setTimeout(foo( ),n);
long_running_fu nction();

Would foo() be executed even when long_running_fu nction() is still
executing? In other words, does the setTimeout() pre-empt anything
else?
Nope. JavaScript is single-threaded, so the return value of foo() won't
be executed until after long_running_fu nction finishes.
[The reason I ask is that I would like to show some feedback to the
user if my long running function takes more than n milliseconds]

Think of it as co-operative multitasking. You'll have to simulate a
yield() in order to allow other code to be executed.

For instance, you can have long_running_fu nction either use global
variables or a closure of some sort to keep track of where it is when
it's about to 'yield', then return() after a
setTimeout(long _running_functi on,1), and have it pick up where it left
off.

Of course, you may also need to ensure that whatever fires off
long_running_fu nction doesn't fire again while it's still running--
since yielding could theoretically make that possible. But that depends
on what it's doing, since of course... it'd pick up where the original
left off, and the original wouldn't continue running until the second
had yielded-- and it would pick up where the second had left off.

Also, long_running_fu nction's return value wouldn't be meaninful, since
it might not finish by the time it return()s.

Just an idea. I'm sure there're better ones out there.

[Randy Webb]

VA said the following on 10/22/2005 11:37 PM:

Suppose I have

setTimeout(foo( ),n);
long_running_fu nction();

Would foo() be executed even when long_running_fu nction() is still
executing?
It would be put in line to be executed if long_running_fu nction() is
still running after n milliseconds. But foo() would not be executed
until the previous function finished.
In other words, does the setTimeout() pre-empt anything else?
No.
[The reason I ask is that I would like to show some feedback to the
user if my long running function takes more than n milliseconds]

Break long running function into sub routines and set a timeout to
execute them. Or, simply have an animated gif that you display before
executing long_running_fu nction that says it's busy.

--
Randy
comp.lang.javas cript FAQ - http://jibbering.com/faq & newsgroup weekly

[Gomolyako Eduard]

VA wrote:

Suppose I have

setTimeout(foo( ),n);
long_running_fu nction();

Would foo() be executed even when long_running_fu nction() is still
executing? In other words, does the setTimeout() pre-empt anything
else?

[The reason I ask is that I would like to show some feedback to the
user if my long running function takes more than n milliseconds]

Thanks

I'm agree with others writers at this topic.

May be my advice help you. 2 iframes on page like a 2 threads in
process. You can run long function at iframe and use setTimeout() on
the top page.

Sorry for my english..

[Thomas 'PointedEars' Lahn]

Random wrote:

VA wrote:

Suppose I have
[1] setTimeout(foo( ),n);
long_running_fu nction();

Would foo() be executed even when long_running_fu nction() is still
executing? In other words, does the setTimeout() pre-empt anything
else?

Nope. JavaScript is single-threaded, so the return value of foo() won't
be executed until after long_running_fu nction finishes.

Rubbish. Have you even bothered to try? JS evaluation is single-threaded,
but that does not mean that only one line of code can be evaluated at the
same time. It means instead that lines of code can only be evaluated at
approximately the same time if they are in different contextes. This is
the case here.

Evaluation within long_running_fu nction() (short for later: lrf()) takes
place within its *local* context, while the evaluation of the return value
of foo() takes place in the *global* context. If lrf() is still running
after approximately n milliseconds, the return value of foo() as it has
been *before* the call of lrf() is evaluated. Try

function foo()
{
return "alert(j);" ;
}

var j;

function lrf()
{
for (var i = 0; i < 1000; i++)
{
for (j = 0; j < 1000; j++);
}
}

setTimeout(foo( ), 25);
lrf();

The alert() box said 919 when I tested. Which means that the
script engine was still executing lrf() at the time it appeared.

However, it seems that the OP was looking for

setTimeout(foo, n);

or

setTimeout("foo ()", n);

instead, where foo() would be *called* after approximately n milliseconds
even if lrf() was still running.
PointedEars

[Random]

Thomas 'PointedEars' Lahn wrote:

JavaScript is single-threaded, so the return value of foo() won't
be executed until after long_running_fu nction finishes.
Rubbish. Have you even bothered to try?

Yes, and I am alternately frustrated and relieved that it doesn't work.

<snip /> function foo()
{
return "alert(j);" ;
}

var j;

function lrf()
{
for (var i = 0; i < 1000; i++)
{
for (j = 0; j < 1000; j++);
}
}

setTimeout(foo( ), 25);
lrf();

The alert() box said 919 when I tested. Which means that the
script engine was still executing lrf() at the time it appeared.
Gives me 1000 every time.
Except when it set it to go for 10000 i's and 10000 j's. Then it gave
me 10000. (And it took a while and a lot of clicks to tell it to keep
going, believe me.)

Both FireFox and IE on Win2000.

For obvious reasons, I only did one run of 10000 i's & 10000 j's, on
each browser, but the results were the same.

However, it seems that the OP was looking for

setTimeout(foo, n);

or

setTimeout("foo ()", n);

instead, where foo() would be *called* after approximately n milliseconds
even if lrf() was still running.

Quite probably.
--
-r

[Thomas 'PointedEars' Lahn]

Random wrote:

Thomas 'PointedEars' Lahn wrote:

function foo()
{
return "alert(j);" ;
}

var j;

function lrf()
{
for (var i = 0; i < 1000; i++)
{
for (j = 0; j < 1000; j++);
}
}

setTimeout(foo( ), 25);
lrf();

The alert() box said 919 when I tested. Which means that the
script engine was still executing lrf() at the time it appeared.
Gives me 1000 every time.
Except when it set it to go for 10000 i's and 10000 j's. Then it gave
me 10000.

Of course it depends on the speed of the machine it is running on.
(And it took a while and a lot of clicks to tell it to keep going,
believe me.)
Which also could have influence on the test result.
Both FireFox and IE on Win2000.
I tested with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12)
Gecko/20050922 Firefox/1.0.7 (Debian package 1.0.7-1) Mnenhy/0.7.2.0
on Pentium III (Coppermine), ca. 871 MHz clock rate, 256 KiB cache.

With the original code I get the warning, too, but the value the alert
shows is below 1000 every time (out of 10).
For obvious reasons, I only did one run of 10000 i's & 10000 j's, on
each browser, but the results were the same.

Seems a more reliable test is needed.
PointedEars

[Random]

Thomas 'PointedEars' Lahn wrote:

Random wrote:

Thomas 'PointedEars' Lahn wrote:

function foo()
{
return "alert(j);" ;
}

var j;

function lrf()
{
for (var i = 0; i < 1000; i++)
{
for (j = 0; j < 1000; j++);
}
}

setTimeout(foo( ), 25);
lrf();

The alert() box said 919 when I tested. Which means that the
script engine was still executing lrf() at the time it appeared.

Gives me 1000 every time.
Except when it set it to go for 10000 i's and 10000 j's. Then it gave
me 10000.

Of course it depends on the speed of the machine it is running on.

Which was the main reason I tried the 10000 iterations, actually. Just
to be sure.

(And it took a while and a lot of clicks to tell it to keep going,
believe me.)

Which also could have influence on the test result.

Indeed, but I didn't get the message 'a script on this page is causing
[Firefox/Internet Explorer] to run slowly' on the 1000 iteration.

Both FireFox and IE on Win2000.

I tested with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12)
Gecko/20050922 Firefox/1.0.7 (Debian package 1.0.7-1) Mnenhy/0.7.2.0
on Pentium III (Coppermine), ca. 871 MHz clock rate, 256 KiB cache.

With the original code I get the warning, too, but the value the alert
shows is below 1000 every time (out of 10).

Don't mean to be insulting, but have to be detailed: you didn't just
hit enter/spacebar on the alert, right? The default selection (in both
IE & FF on Win2k) is to stop the script. (OK/Cancel in FF-- have to hit
cancel for it to keep running; Yes/No in IE-- have to hit no. I made
that mistake once and it came back with something like 4500, which
perturbed me somewhat until I realised what I'd done.)

For obvious reasons, I only did one run of 10000 i's & 10000 j's, on
each browser, but the results were the same.

Seems a more reliable test is needed.

If you can think of one. I'm not sure what else could be done, beyond
10000*10000 iterations, waiting for an alert. I would think the 'error'
message would give it a perfect opportunity to yield to another opcode
(to borrow a concept from another language) if that's what it were
going to do. Even so, 25 milliseconds had definitely come and long-gone
under both 1000^2 and 10000^2.

Like I said, if you can think of a more reliable test (given available
hardware), I'm game.

--
-r

[bgulian]

Thomas 'PointedEars' Lahn wrote:

I tested with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12)
Gecko/20050922 Firefox/1.0.7 (Debian package 1.0.7-1) Mnenhy/0.7.2.0
on Pentium III (Coppermine), ca. 871 MHz clock rate, 256 KiB cache.

With the original code I get the warning, too, but the value the alert
shows is below 1000 every time (out of 10).

I got 1000 every time on XP with IE 6.0 and Firefox 1.06. I and my
colleagues have done extensive testing on the Windows platform and IE
because our business depends on interaction between ActiveX controls
and Javascript. Javascript is indeed single threaded.

Obviously there are parts of the browser's rendering engine that are
not single threaded, image loading and rendering, object loading. It
disturbs me that Mozilla's implementation on Linux is somehow causing
javascript evaluation to get pre-empted. If that's true then what you
are saying about contexts makes sense.

However, I can say that I have never seen it happen on the Window's
platform and like Random, I'm both relieved and frustrated.

beegee