Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

[ Suggestion ] The iterator case still needs work. #2

Closed
azoff opened this Issue Oct 3, 2011 · 2 comments

Comments

Projects
None yet
2 participants

azoff commented Oct 3, 2011

I like where you are going with async and await and, in the interest of delivering on the goal of code-clarity, I believe the following use case should be addressed:

In the use case where a callback is called multiple times, e.g. an iterator callback, the execution flow is not clear. Here is a more concrete example:

someArray.each(function(index, element){  /* do something with each element. */  });

turns into

await index, element = someArray.each()
// do something with each element?

In the interest of full-disclosure, I have not yet played around with your fork - so I do not even know what type of execution path this code would take. For instance, I am not sure if this code will:

  • Run through the entire loop, and only set index and element to the values of the last iteration or,
  • Re-run the synchronous code after the iterator, for every element.

The first option seems totally broken for looping, and the second seems to work like a goto statement (which, to save argument against goto, just doesn't seem to accomplish the goal of code clarity.

My suggestion: We stylistically avoid using await for iterator-like callbacks (kind of like a best-practice) instead of blocking the case all together. If one should choose to use the async syntax for an iterator, then the returned values are Iterators (representing the eventual arguments for the iteration):

await indices, elements = someArray.each()
typeof elements; // Iterator
while (element = elements.next()) {  /* do something with each element. */  }

For what it's worth, I think Mozilla already has something in the pipe that will help design for this use case: https://developer.mozilla.org/en/JavaScript/Guide/Iterators_and_Generators

Just my two cents, but this case needs to be cleared up for me to be on this boat :)

Owner

koush commented Oct 3, 2011

I am juggling whether I want to support reentrance of an await (allowing an awaited statement to be called multiple times via the callback/each), but have not tested this scenario at all. So, the continuation can currently be called as many times as you want, but I am fairly certain it will not work properly. Specifically around awaits embedded in loops and try/catch statements.

I agree with your assessment that using await on iterator like callbacks is not ideal. At the moment, I am leaning towards making it throw an exception if it is reentered.

Re: Mozilla, I do want to add yield support.

koush pushed a commit that referenced this issue Apr 25, 2013

src: don't SetInternalField() in ObjectWrap dtor
Call SetPointerInInternalField(0, NULL) rather than
SetInternalField(0, Undefined()).

Fixes the following spurious NULL pointer dereference in debug builds:

  #0  0x03ad2821 in v8::internal::FixedArrayBase::length ()
  #1  0x03ad1dfc in v8::internal::FixedArray::get ()
  #2  0x03ae05dd in v8::internal::Context::global_object ()
  #3  0x03b6b87d in v8::internal::Context::builtins ()
  #4  0x03ae1871 in v8::internal::Isolate::js_builtins_object ()
  #5  0x03ab4fab in v8::CallV8HeapFunction ()
  #6  0x03ab4d4a in v8::Value::Equals ()
  #7  0x03b4f38b in CheckEqualsHelper ()
  #8  0x03ac0f4b in v8::Object::SetInternalField ()
  #9  0x06a99ddd in node::ObjectWrap::~ObjectWrap ()
  #10 0x06a8b051 in node::Buffer::~Buffer ()
  #11 0x06a8afbb in node::Buffer::~Buffer ()
  #12 0x06a8af5e in node::Buffer::~Buffer ()
  #13 0x06a9e569 in node::ObjectWrap::WeakCallback ()
Owner

koush commented Apr 27, 2013

implemented yield.

@koush koush closed this Apr 27, 2013

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment