I'm specifically worried about function*. My concern is that, unlike in the
fibers community, the vast majority of these generators will run every
iteration to completion before a turn of the event loop. The assumption then
becomes: "I won't have two parallel iterations" and people will think parts of
their scope are isolated more than they are.
Again, I think it is very analogous to the confusion over our current function
iterators when they are made async without visible changes like names or
callbacks being added.
When you see:
blah.forEach(function (obj) { /* do something */ })
You assume it's going to block until completion because you've been conditioned
to think that way. There's obviously nothing in the language saying that all
the iterations will run right away but you've seen it so many times you just
begin to make that assumption. It's a lot of additional cognitive overhead to
worry about state mutations in every iterator so we choose to ignore the
possibility.
My experience with earlier iterations (no PUN intended) of generators in the
Mozilla platform leads me to think they'll be used as fancy/clever for loops
quite often and I have a hard time believing that developers will learn to
worry about state mutation in their for loops or future replacements thereof.
-Mikeal
On Aug 5, 2013, at 4:01PM, Marcel Laverdet <mar...@laverdet.com> wrote:
> Mikeal correct me if I'm wrong as I haven't thought about it that much, but
> even with ES6 generators a function *must* run to completion before a turn of
> the event loop unless it's explicitly marked as a generator itself
> (function*). This isn't a guideline but a technical limitation as generators
> are single-frame (in contrast to fibers which don't follow your terrestrial
> rules). Thus you're not going to run into the case where innocent client code
> is waylaid down the stack by a generator. The only functions that need to
> worry about reentrancy are those that are explicitly marked as function*.
>
>
> On Mon, Aug 5, 2013 at 4:40 PM, Mikeal Rogers <mikeal.rog...@gmail.com> wrote:
> I don't think you understand what I'm saying, I'll try to be clearer.
>
> Callbacks that use node's standard callback interface are resolved exactly
> once. From the point at which they begin to when they end the author can
> assume that any code they are running is the *only* code running in the VM
> and that state will only mutate between other callbacks passed to other APIs
> before resolving the callback they were given. In other words, state mutation
> boundaries are visible, explicit and consistent.
>
> Generators iterate over data in an iterable manor but because they cannot
> yield between turns of the event loop their condition is assumed to be
> resolved in one stack. For instance, if I offer you a generator my assumption
> is that if you present an API to another consumer that consumer will *also*
> call yield on your API to consume it iterably or consumer the entire
> generator until completion.
>
> While it is certainly *possible* that someone might decide not to offer a
> yield API and instead to turn the event loop before I'm finished and keep the
> generator yielded between cycles, I would bet that most people assume it
> won't happen and won't make attempts to be safe between concurrent iterations
> of the same generator.
>
> My concern is not that generators are "magical" but that the current
> implementation *appears* to offer assurances that *we* will go out and break.
>
> Similar problems have crept in to node libraries that called asynchronous
> iterators "forEach" and their consumers assumed that this blocked the VM
> since Array.forEach blocks the VM until completion.
>
> If 95% of the time generator authors don't have to worry about maintaining
> safety between concurrent iterations of the same generator history shows that
> a good number of them never will and will just break at scale in really fun
> (horrendous) to debug ways.
>
> -Mikeal
>
> On Aug 5, 2013, at 2:18PM, Christopher Probst
> <foxnet.develo...@googlemail.com> wrote:
>
>> The generators are not magical. They do basically the same as callbacks but
>> they invert the inversion of control optically.
>>
>> --
>> --
>> Job Board: http://jobs.nodejs.org/
>> Posting guidelines:
>> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
>> You received this message because you are subscribed to the Google
>> Groups "nodejs" group.
>> To post to this group, send email to nodejs@googlegroups.com
>> To unsubscribe from this group, send email to
>> nodejs+unsubscr...@googlegroups.com
>> For more options, visit this group at
>> http://groups.google.com/group/nodejs?hl=en?hl=en
>>
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "nodejs" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to nodejs+unsubscr...@googlegroups.com.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>
>
> --
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups
> "nodejs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to nodejs+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
>
> --
> --
> Job Board: http://jobs.nodejs.org/
> Posting guidelines:
> https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
> You received this message because you are subscribed to the Google
> Groups "nodejs" group.
> To post to this group, send email to nodejs@googlegroups.com
> To unsubscribe from this group, send email to
> nodejs+unsubscr...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/nodejs?hl=en?hl=en
>
> ---
> You received this message because you are subscribed to the Google Groups
> "nodejs" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to nodejs+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
--
--
Job Board: http://jobs.nodejs.org/
Posting guidelines:
https://github.com/joyent/node/wiki/Mailing-List-Posting-Guidelines
You received this message because you are subscribed to the Google
Groups "nodejs" group.
To post to this group, send email to nodejs@googlegroups.com
To unsubscribe from this group, send email to
nodejs+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/nodejs?hl=en?hl=en
---
You received this message because you are subscribed to the Google Groups
"nodejs" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to nodejs+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
