Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Why are event loops bad?

68 views
Skip to first unread message

Dave Townsend

unread,
Apr 14, 2011, 11:53:25 PM4/14/11
to dev-platform
The story I've consistently heard (and even parroted myself) is that writing
your own event loop in JS is a Bad Thing and to be avoided at all costs.
I've never totally understood why though. In particular why is it bad when
opening a modal window (which basically runs its own event loop) is fine?

L. David Baron

unread,
Apr 15, 2011, 12:09:56 AM4/15/11
to Dave Townsend, dev-platform

One reason is that there's the issue of the code that's on the stack
above your code that's spinning a nested event loop: it's probably
processing a particular event, and it won't finish doing so until
your nested event loop returns. If that nested event loop happens
to get an event going to the same code -- things are likely to get
confused. For example, the later event, processed by the nested
event loop, could mutate or destroy data structures that the code
above your event makes some assumptions about.

So, in other words, any code that might call something that might
start a nested event loop needs to be prepared for pretty much
anything changing across that function call. And that's hard, and a
lot of code doesn't get it right, even when (not guaranteed) the
author is aware of the potential problem.


There are probably other problems as well.

-David

--
L. David Baron http://dbaron.org/
Mozilla Corporation http://www.mozilla.com/

Henri Sivonen

unread,
Apr 15, 2011, 4:34:09 AM4/15/11
to dev-platform
On Thu, 2011-04-14 at 20:53 -0700, Dave Townsend wrote:
> In particular why is it bad when
> opening a modal window (which basically runs its own event loop) is
> fine?

Surely that's bad and not "fine". It's just the kind of bad that's hard
to remove.

--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/

Ehsan Akhgari

unread,
Apr 15, 2011, 10:24:20 AM4/15/11
to L. David Baron, dev-platform, Dave Townsend
David is right. The really bad thing about such problems is that they
might be very hard to reproduce, and finding the problem by analyzing
the code might be extremely hard. See bug 616288 for an example, caused
by JS code using generators.

Cheers,
Ehsan

On 11-04-15 12:09 AM, L. David Baron wrote:
> On Thursday 2011-04-14 20:53 -0700, Dave Townsend wrote:
>> The story I've consistently heard (and even parroted myself) is that writing
>> your own event loop in JS is a Bad Thing and to be avoided at all costs.

>> I've never totally understood why though. In particular why is it bad when


>> opening a modal window (which basically runs its own event loop) is fine?
>

Neil

unread,
Apr 15, 2011, 11:22:20 AM4/15/11
to
Ehsan Akhgari wrote:

> See bug 616288 for an example, caused by JS code using generators.

Why are StartSearch implementation(s) spinning event loops in the first
place? Doesn't that defeat the point of it being an asynchronous API?

--
Warning: May contain traces of nuts.

Ehsan Akhgari

unread,
Apr 15, 2011, 4:04:55 PM4/15/11
to Neil, dev-pl...@lists.mozilla.org
On 11-04-15 11:22 AM, Neil wrote:
> Ehsan Akhgari wrote:
>
>> See bug 616288 for an example, caused by JS code using generators.
>
> Why are StartSearch implementation(s) spinning event loops in the first
> place? Doesn't that defeat the point of it being an asynchronous API?

They're using JavaScript generators, which are implemented using nested
event loops. Which makes it possible for JavaScript code to spin the
event loop without the author realizing it. :(

Ehsan

Kyle Huey

unread,
Apr 15, 2011, 4:14:53 PM4/15/11
to Ehsan Akhgari, Neil, dev-pl...@lists.mozilla.org
This sounds like something we need to be avoiding in product code and tests
that aren't designed to test generators then.

- Kyle

On Fri, Apr 15, 2011 at 4:04 PM, Ehsan Akhgari <ehsan....@gmail.com>wrote:

> On 11-04-15 11:22 AM, Neil wrote:
>

>> Ehsan Akhgari wrote:
>>
>> See bug 616288 for an example, caused by JS code using generators.
>>>
>>
>> Why are StartSearch implementation(s) spinning event loops in the first
>> place? Doesn't that defeat the point of it being an asynchronous API?
>>
>

> They're using JavaScript generators, which are implemented using nested
> event loops. Which makes it possible for JavaScript code to spin the event
> loop without the author realizing it. :(
>
> Ehsan
>

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

Ehsan Akhgari

unread,
Apr 15, 2011, 4:18:18 PM4/15/11
to Kyle Huey, Neil, dev-pl...@lists.mozilla.org
On 11-04-15 4:14 PM, Kyle Huey wrote:
> This sounds like something we need to be avoiding in product code and tests
> that aren't designed to test generators then.

I would agree, but I'm not a front-end peer... :(

Please note that generators give the programmers a very clean way to do
some things (syntactically, that is), so people might be inclined to use
them for code simplicity reasons, even when they're not absolutely
necessary.

Cheers,
Ehsan

Dave Townsend

unread,
Apr 15, 2011, 6:35:37 PM4/15/11
to Ehsan Akhgari, Neil, dev-pl...@lists.mozilla.org
This is pretty surprising to me and I don't really understand why it'd need
an event loop. When does it happen? Sounds like generators are a pretty bad
idea if it allows other code to run during what is essentially some
synchronous code.

I have a generator I use all over the place in the add-ons manager code,
should I be trying to get rid of that?

On 15 April 2011 13:04, Ehsan Akhgari <ehsan....@gmail.com> wrote:

> On 11-04-15 11:22 AM, Neil wrote:
>

>> Ehsan Akhgari wrote:
>>
>> See bug 616288 for an example, caused by JS code using generators.
>>>
>>
>> Why are StartSearch implementation(s) spinning event loops in the first
>> place? Doesn't that defeat the point of it being an asynchronous API?
>>
>

Benjamin Smedberg

unread,
Apr 15, 2011, 6:54:19 PM4/15/11
to Ehsan Akhgari, Neil, dev-pl...@lists.mozilla.org
On 4/15/11 4:04 PM, Ehsan Akhgari wrote:
>
> They're using JavaScript generators, which are implemented using
> nested event loops. Which makes it possible for JavaScript code to
> spin the event loop without the author realizing it. :(
JS generators don't necessarily have anything to do with event loops,
and I don't think they have anything to do with this discussion.

--BDS

Ehsan Akhgari

unread,
Apr 15, 2011, 7:23:15 PM4/15/11
to Benjamin Smedberg, Neil, dev-pl...@lists.mozilla.org

Yeah, I think Benjamin is right. I don't remember exactly what I saw in
bug 616288, but I confirmed with the folks in #jsapi that I'm wrong.

Sorry for the noise!

Ehsan

Boris Zbarsky

unread,
Apr 15, 2011, 7:34:06 PM4/15/11
to
On 4/15/11 4:04 PM, Ehsan Akhgari wrote:
> They're using JavaScript generators, which are implemented using nested
> event loops.

They're not, no. JS generators just put a JS stack frame on the heap
instead of on the C stack, so it can persist even as the actual C stack
unwinds. Then you can call back into the generator at the point where
you left it.

If the event loop actually spins, something needs to explicitly spin it,
typically.

I just looked at bug 616288 and what's happening there is that
nsAutoCompleteController::StartSearch calls some JS which directly calls
nsIThread::ProcessNextEvent, as far as I can tell. I haven't found the
caller there yet, though if people can reproduce that would be worth
finding.

As for the generator mentioned in that bug, it looks like this if I
strip out the irrelevant stuff:

function doSearch(/* some arguments */) {
var newResult = new TagAutoCompleteResult(searchString,
Ci.nsIAutoCompleteResult.RESULT_SUCCESS, 0, "", results,
comments);
listener.onSearchResult(self, newResult);
yield false;
}

var gen = doSearch();
while (gen.next());
gen.close();

which is a fancy + confusing way of just calling doSearch() once without
any of that generator business. There's some commented out code that
could return true, but it's commented out.

-Boris

Ehsan Akhgari

unread,
Apr 15, 2011, 9:26:51 PM4/15/11
to Boris Zbarsky, dev-pl...@lists.mozilla.org
On 11-04-15 7:34 PM, Boris Zbarsky wrote:
> I just looked at bug 616288 and what's happening there is that
> nsAutoCompleteController::StartSearch calls some JS which directly calls
> nsIThread::ProcessNextEvent, as far as I can tell. I haven't found the
> caller there yet, though if people can reproduce that would be worth
> finding.

The STRs are in the bug, and IIRC it was trivial to reproduce in a debug
build, so if somebody wants, they can back out my fix and give it a shot.

> As for the generator mentioned in that bug, it looks like this if I
> strip out the irrelevant stuff:
>
> function doSearch(/* some arguments */) {
> var newResult = new TagAutoCompleteResult(searchString,
> Ci.nsIAutoCompleteResult.RESULT_SUCCESS, 0, "", results,
> comments);
> listener.onSearchResult(self, newResult);
> yield false;
> }
>
> var gen = doSearch();
> while (gen.next());
> gen.close();
>
> which is a fancy + confusing way of just calling doSearch() once without
> any of that generator business. There's some commented out code that
> could return true, but it's commented out.

I've filed bug 650427 about that.

Ehsan

0 new messages