Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #24072 > unrolled thread

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

Back to article view | Back to comp.lang.java.programmer

Contents

  A JavaScript setTimeout() even canNOT interrupt a currently executing setTomeout() event! Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2013-05-15 22:44 +0800
    Re: A JavaScript setTimeout() even canNOT interrupt a currently executing setTomeout() event! markspace <markspace@nospam.nospam> - 2013-05-15 08:58 -0700
      Re: A JavaScript setTimeout() even canNOT interrupt a currently executing setTomeout() event! Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2013-05-16 19:14 +0800
        Re: A JavaScript setTimeout() even canNOT interrupt a currently executing setTomeout() event! markspace <markspace@nospam.nospam> - 2013-05-16 07:44 -0700
    Re: A JavaScript setTimeout() even canNOT interrupt a currently executing setTomeout() event! "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2013-05-16 00:01 +0200
      Re: A JavaScript setTimeout() even canNOT interrupt a currently executing setTomeout() event! Richard Maher <maher_rjSPAMLESS@hotmail.com> - 2013-05-16 19:02 +0800

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

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

[toc] | [next] | [standalone]

#24073

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.

[toc] | [prev] | [next] | [standalone]

#24097

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.

[toc] | [prev] | [next] | [standalone]

#24100

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.

[toc] | [prev] | [next] | [standalone]

#24080

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)

[toc] | [prev] | [next] | [standalone]

#24095

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

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web