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/
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/
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?
>
> 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.
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
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
>
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
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?
>>
>
--BDS
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
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
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