A JavaScript setTimeout() even canNOT interrupt a currently executing setTomeout() event!

[Richard Maher]

If, like me, you hold this truth to be self-evident then please bring
your pitch-fork to the castle door of: -
https://bugzilla.mozilla.org/show_bug.cgi?id=856969#c44

(Java/Liveconnect is the facilitator)

Is it a GTK, Geko, Windows issue?

Cheers Richard Maher

[markspace]

On 5/15/2013 7:44 AM, Richard Maher wrote:
> If, like me, you hold this truth to be self-evident then please bring
> your pitch-fork to the castle door of: -

No.

> https://bugzilla.mozilla.org/show_bug.cgi?id=856969#c44
>
> (Java/Liveconnect is the facilitator)
>
> Is it a GTK, Geko, Windows issue?

I followed a bit from the last post you made on this issue, and I'm
pretty sure the issue is not GTK, Geko, or Windows, but in the general
vicinity of your chair.

They're being very nice and explaining why the issue exists and cannot
be changed. You have to change your own code. It's the only way.

[Evertjan.]

Richard Maher wrote on 15 mei 2013 in comp.lang.javascript:

> A JavaScript setTimeout() even canNOT interrupt
> a currently executing setTimeout() event!

> If, like me, you hold this truth to be self-evident ..

More general, setTimeOut() does not fire while script is being executed,
as Javascript [in browsers and probably elsewhere] at present is both
single threaded and uninteruptable.

Otherwise it just fires after the script-execution ends.

Even more so, setTimeout() only executes momentarily by calling a function
or a code string.

So not so self-evident.

--
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[Richard Maher]

On 5/16/2013 6:01 AM, Evertjan. wrote:
> Richard Maher wrote on 15 mei 2013 in comp.lang.javascript:
>
>> A JavaScript setTimeout() even canNOT interrupt
>> a currently executing setTimeout() event!
>
>> If, like me, you hold this truth to be self-evident ..
>
> More general, setTimeOut() does not fire while script is being executed,
> as Javascript [in browsers and probably elsewhere] at present is both
> single threaded and uninteruptable.
>
> Otherwise it just fires after the script-execution ends.
>
> Even more so, setTimeout() only executes momentarily by calling a function
> or a code string.
>
> So not so self-evident.
>

Thanks. The penny is beginning to drop, and my foolish notion of
separate execution contexts for an "event" -vs- "mainline" in JavaScript
sees me looking like a numpty harkening to days gone by :-(

IIUYC, once an event is executing (e.g. a setTimeout() function or
string) then it is just another chunk of inline JavaScript that can't
(the focus() and inline event examples notwithstanding) or won't be
interrupted until it's run. At which time the main loop will look to the
event queue(s) and decide what to do.

Obviously, in my case, the Java Plugin changes the ball-game but that's
why I love it and take advantage of it!

Cheers Richard Maher

[Richard Maher]

On 5/15/2013 11:58 PM, markspace wrote:
> On 5/15/2013 7:44 AM, Richard Maher wrote:
>> If, like me, you hold this truth to be self-evident then please bring
>> your pitch-fork to the castle door of: -
>
> No.

You're not much fun then. So the torch is out of the question?

>
>> https://bugzilla.mozilla.org/show_bug.cgi?id=856969#c44
>>
>> (Java/Liveconnect is the facilitator)
>>
>> Is it a GTK, Geko, Windows issue?
>
> I followed a bit from the last post you made on this issue, and I'm
> pretty sure the issue is not GTK, Geko, or Windows, but in the general
> vicinity of your chair.

Look, you're most probably correct but it's just that ALL the WebKit
browsers behave and do what they should and even *FireFox* on OS/X is
unbreakable with my example. (Regardless of setTimeout()s,
Thread.Sleep()s, and the number of JS Tester() objects.

I bet my right gonad that no one here can *SHOW* me otherwise!

>
> They're being very nice and explaining why the issue exists and cannot
> be changed.

Some of the nicest, high-calibre, selfless people I've met in IT! If
they could just tell me why FireFox OS/X doesn't miss a beat then I'll
go away a happy man.

> You have to change your own code. It's the only way.
>
>
>

Looks that way. I can deal with that.

[markspace]

On 5/16/2013 4:14 AM, Richard Maher wrote:
>
> Look, you're most probably correct but it's just that ALL the WebKit
> browsers behave and do what they should and even *FireFox* on OS/X is
> unbreakable with my example. (Regardless of setTimeout()s,
> Thread.Sleep()s, and the number of JS Tester() objects.

Well as explained in that CR, there probably isn't a difference in the
browser. It's just due to timing or other differences in the
environment. You're going to have the same problem, or a worse one, no
matter what.

> I bet my right gonad that no one here can *SHOW* me otherwise!

You can show us yourself, you know. Firefox is open source. Get the
source, locate the bug and turn in a patch. That's the right way to
complain about somebody else's software.

> Looks that way. I can deal with that.

This at least is a good attitude. There's a fine line between
perseverance and getting diagnosed with OCD. I think it might be time
to cut bait on this one and live with it.