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

Groups > comp.lang.javascript > #36383 > unrolled thread

Re: Asynchronous Loops in the Browser?

Back to article view | Back to comp.lang.javascript

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Asynchronous Loops in the Browser? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-04-22 02:42 +0200
    Re: Asynchronous Loops in the Browser? Luuk <luuk@invalid.lan> - 2019-04-22 08:54 +0200
    Re: Asynchronous Loops in the Browser? Luuk <luuk@invalid.lan> - 2019-04-22 08:54 +0200
    Re: Asynchronous Loops in the Browser? Luuk <luuk@invalid.lan> - 2019-04-22 08:55 +0200
    Re: Asynchronous Loops in the Browser? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-04-22 11:13 +0100
      Re: Asynchronous Loops in the Browser? "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2019-04-22 12:20 +0200
      Re: Asynchronous Loops in the Browser? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-04-22 12:53 +0200
        Re: Asynchronous Loops in the Browser? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-04-22 17:05 +0100
          Re: Asynchronous Loops in the Browser? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-04-22 19:19 +0200
            Re: Asynchronous Loops in the Browser? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-04-22 23:49 +0100
              Re: Asynchronous Loops in the Browser? Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2019-04-23 11:58 +0200

#36383 — Re: Asynchronous Loops in the Browser?

Stefan Ram wrote:
> |>> print(1)
> |<- 1
> |>> while(1);
>
>   offering me a new prompt.

No, it does not, for the Console tab is stuck then.

> But the endless loop still seems to be running in some kind of background?

JFTR:

Stefan Ram is a known Usenet troll.  All he ever does is starting new
threads and posting his absurd, clueless theses; he never actually studies
the subject before he is posting about it, or engages in a discussion.
Do not feed the troll.

In this case, however, I must react to this because the code that he posts
is positively harmful.  In Firefox ESR 52.9.0 (64-bit) on GNU/Linux, such a
tight loop drives CPU usage to 100 %, thus drives the CPU fan up, and can
cause the CPU to overheat.  Only sometimes there is a message warning about
an unresponsive process in which the “Stop Script” button can be used to
terminate it.

>   So, is everything I enter into the browser console
>   executed in its own thread?
> 
>   If so, where/how can I see and stop those threads?

In Firefox, where there is only one process, the only way to solve the
problem (if the warning message does not appear) is to kill the browser
process (e.g., Ctrl+Alt+Esc, then click with the death pointer, in the
X Window System).

In Chromium-based browsers, where each tab is executed as a separate
process, it suffices to close or kill the tab (via the Chromium Task
Manager, triggered also with Shift+Esc, or via the Task Manager of
the desktop environment [e.g. KRunner triggered by Ctrl+Esc by default,
or KSysGuard] or operating system [e.g. top(1)]).

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [next] | [standalone]

#36385

On 22-4-2019 02:42, Thomas 'PointedEars' Lahn wrote:
> Stefan Ram wrote:
>> |>> print(1)
>> |<- 1
>> |>> while(1);
>>
>>    offering me a new prompt.
> 
> No, it does not, for the Console tab is stuck then.
> 
>> But the endless loop still seems to be running in some kind of background?
> 
> JFTR:
> 
> Stefan Ram is a known Usenet troll. 
There are more of them, i do mean "usenet troll's"...


-- 
Luuk

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

#36386

On 22-4-2019 02:42, Thomas 'PointedEars' Lahn wrote:
> Stefan Ram wrote:
>> |>> print(1)
>> |<- 1
>> |>> while(1);
>>
>>    offering me a new prompt.
> 
> No, it does not, for the Console tab is stuck then.
> 
>> But the endless loop still seems to be running in some kind of background?
> 
> JFTR:
> 
> Stefan Ram is a known Usenet troll. 
There are more of them, i do mean "usenet troll's"...


-- 
Luuk

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

#36387

On 22-4-2019 02:42, Thomas 'PointedEars' Lahn wrote:
> Stefan Ram wrote:
>> |>> print(1)
>> |<- 1
>> |>> while(1);
>>
>>    offering me a new prompt.
> 
> No, it does not, for the Console tab is stuck then.
> 
>> But the endless loop still seems to be running in some kind of background?
> 
> JFTR:
> 
> Stefan Ram is a known Usenet troll. 
There are more of them, i do mean "usenet troll's"...


-- 
Luuk

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

#36388

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:

> Stefan Ram wrote:
>> |>> print(1)
>> |<- 1
>> |>> while(1);
>>
>>   offering me a new prompt.
>
> No, it does not, for the Console tab is stuck then.

No doubt that sometimes happens, but the behaviour (for the 'while')
described by Stefan Ram is also a possibility.  It's what I see in the
three Linux browsers I tested.

<cut>
> In Firefox, where there is only one process, the only way to solve the
> problem (if the warning message does not appear) is to kill the browser
> process (e.g., Ctrl+Alt+Esc, then click with the death pointer, in the
> X Window System).

When I try it with Firefox, I get (as SR suggested) a fresh and
responsive console prompt, and I can simply close the browser normally
and the CPU usage goes back to idle.  What one sees, and how to deal
with it, is obviously system-dependent.

<cut>
-- 
Ben.

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

#36389

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote on 22 Apr 2019 in 
comp.lang.javascript:

> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
> 
>> Stefan Ram wrote:
>>> |>> print(1)
>>> |<- 1
>>> |>> while(1);
>>>
>>>   offering me a new prompt.
>>
>> No, it does not, for the Console tab is stuck then.
> 
> No doubt that sometimes happens, but the behaviour (for the 'while')
> described by Stefan Ram is also a possibility.  It's what I see in the
> three Linux browsers I tested.
> 
> <cut>
>> In Firefox, where there is only one process, the only way to solve the
>> problem (if the warning message does not appear) is to kill the browser
>> process (e.g., Ctrl+Alt+Esc, then click with the death pointer, in the
>> X Window System).
> 
> When I try it with Firefox, I get (as SR suggested) a fresh and
> responsive console prompt, and I can simply close the browser normally
> and the CPU usage goes back to idle.  What one sees, and how to deal
> with it, is obviously system-dependent.
> 
> <cut>

Crossing a motorway is rather dangerous, 
crossing a farmers road less so,
crossing by overpath or subway is a good general alternative.
[Transponders will use other words.]

When programming for others on the web, 
safe programming is the logical and most friendly thing to do.


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

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

#36390

Ben Bacarisse wrote:
> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>> Stefan Ram wrote:
>>> |>> print(1)
>>> |<- 1
>>> |>> while(1);
>>>
>>>   offering me a new prompt.
>> No, it does not, for the Console tab is stuck then.
> 
> No doubt that sometimes happens, but the behaviour (for the 'while')
> described by Stefan Ram is also a possibility.  It's what I see in the
> three Linux browsers I tested.

Which browsers have you tested under which "Linux"?

> <cut>
>> In Firefox, where there is only one process, the only way to solve the
>> problem (if the warning message does not appear) is to kill the browser
>> process (e.g., Ctrl+Alt+Esc, then click with the death pointer, in the
>> X Window System).
> 
> When I try it with Firefox, I get (as SR suggested) a fresh and
> responsive console prompt, and I can simply close the browser normally
> and the CPU usage goes back to idle.  What one sees, and how to deal
> with it, is obviously system-dependent.

As I indicated in the part that you trimmed, I have tested with
navigator.userAgent === `Mozilla/5.0 (X11; Linux x86_64; rv:52.0)
Gecko/20100101 Firefox/52.0`.  The most recent version is 66.0.2, but 52.0
is the most recent version installable with my package manager.

With which Firefox version have you tested?

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#36393

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:

> Ben Bacarisse wrote:
>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>>> Stefan Ram wrote:
>>>> |>> print(1)
>>>> |<- 1
>>>> |>> while(1);
>>>>
>>>>   offering me a new prompt.
>>> No, it does not, for the Console tab is stuck then.
>> 
>> No doubt that sometimes happens, but the behaviour (for the 'while')
>> described by Stefan Ram is also a possibility.  It's what I see in the
>> three Linux browsers I tested.
>
> Which browsers have you tested under which "Linux"?

epiphany-browser 3.30.1-1ubuntu2 (AKA "Web")
chromium-browser 73.0.3683.86-0ubuntu0.18.10.1
firefox 66.0.3+build1-0ubuntu0.18.10.1

Linux 4.18.0-17-generic #18-Ubuntu SMP

<cut>
> With which Firefox version have you tested?

See above, but it's possible build options matter as well.  The point
was simply that this is not a "yes it does", "no it doesn't" situation.
It depends.

-- 
Ben.

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

#36394

Ben Bacarisse wrote:
> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>> Ben Bacarisse wrote:
>>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>>>> Stefan Ram wrote:
>>>>> |>> while(1);
>>>>> […]
>>> […] but the behaviour (for the 'while') described by Stefan Ram is also
>>> a possibility.  It's what I see in the three Linux browsers I tested.
>>
>> Which browsers have you tested under which "Linux"?
> 
> epiphany-browser 3.30.1-1ubuntu2 (AKA "Web")
> chromium-browser 73.0.3683.86-0ubuntu0.18.10.1

Note that these are not Mozilla-based.

> firefox 66.0.3+build1-0ubuntu0.18.10.1
> 
> Linux 4.18.0-17-generic #18-Ubuntu SMP

OK.

> <cut>

I do not appreciate your repeatedly "cutting" away parts of my text that are
vital to understand the context.  Learn to quote.

>> With which Firefox version have you tested?
> 
> See above, but it's possible build options matter as well.  The point
> was simply that this is not a "yes it does", "no it doesn't" situation.

I did not say otherwise.  Learn to read.

> It depends.

In the case of Firefox it is likely that the Console behavior with regard
to tight loops has been improved between version 52 (my environment) and
66.0.3 (your environment).

Regardless, my warning was appropriate and necessary.

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

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

#36395

Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:

> Ben Bacarisse wrote:
>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>>> Ben Bacarisse wrote:
>>>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>>>>> Stefan Ram wrote:
>>>>>> |>> while(1);
>>>>>> […]
>>>> […] but the behaviour (for the 'while') described by Stefan Ram is also
>>>> a possibility.  It's what I see in the three Linux browsers I tested.
>>>
>>> Which browsers have you tested under which "Linux"?
>> 
>> epiphany-browser 3.30.1-1ubuntu2 (AKA "Web")
>> chromium-browser 73.0.3683.86-0ubuntu0.18.10.1
>
> Note that these are not Mozilla-based.

Why?

<cut>
> Regardless, my warning was appropriate and necessary.

I was commenting on your telling Stefan Ram he was wrong about the what
he saw happen.

-- 
Ben.

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

#36396

Ben Bacarisse wrote:
> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>> Ben Bacarisse wrote:
>>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>>>> Ben Bacarisse wrote:
>>>>> Thomas 'PointedEars' Lahn <PointedEars@web.de> writes:
>>>>>> Stefan Ram wrote:
>>>>>>> |>> while(1);
>>>>>>> […]
>>>>> […] but the behaviour (for the 'while') described by Stefan Ram is also
>>>>> a possibility.  It's what I see in the three Linux browsers I tested.
>>>> Which browsers have you tested under which "Linux"?
>>> epiphany-browser 3.30.1-1ubuntu2 (AKA "Web")
>>> chromium-browser 73.0.3683.86-0ubuntu0.18.10.1
>> Note that these are not Mozilla-based.
> 
> Why?


I do not understand the point of your question.

To make this discussion shorter, I offer two possible interpretations and
corresponding answers:

A)

  Q: Why is it important to note that these browsers are not Mozilla
     (Gecko/JavaScript)-based?

  A: Because we have been discussing behavior the in SpiderMonkey or Rhino
     shell (Stefan Ram did not state which), Mozilla JavaScript-based
     shells, and Firefox, a Mozilla-based browser.  The behavior of other
     shells and browsers is likely to be different.

B)

  Q: Why are these browsers not Mozilla (Gecko/JavaScript)-based?

  A: Because they are not:

     - Epiphany (GNOME Web) is based on WebKitGTK, a WebKit fork
       ported to GTK+ (Apple WebCore + Apple JavaScriptCore),
       since version 2.28;

     - Chromium is based on Google Blink (WebCore fork + Google V8
       JavaScript) since version 28.

     One must not mistake the substring “Mozilla” in the value of the
     User-Agent header field value (and the “navigator.userAgent” property
     value) to mean that a browser is necessarily Mozilla-based:
     <https://en.wikipedia.org/wiki/User_agent#Use_in_HTTP>

<https://en.wikipedia.org/wiki/GNOME_Web#WebKit-based>
<https://webkitgtk.org/>
<https://en.wikipedia.org/wiki/Chromium_(web_browser)>
<https://en.wikipedia.org/wiki/Blink_(browser_engine)>

>> Regardless, my warning was appropriate and necessary.
> 
> I was commenting on your telling Stefan Ram he was wrong about the what
> he saw happen.

That is not how I meant it, which is why I specified the Firefox version
with which I had tested.

-- 
PointedEars

Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web