Enumerator#next proceeds to next iteration without being called again #5007
Milestone
Comments
headius
added a commit
that referenced
this issue
Jan 24, 2018
Due to a bug in how Enumerator#next progresses (it will run an iteration ahead of requested) this bug was exposed as #4903 where an Enumerator#next-based sink for IO.copy_stream showed previously-returned results getting modified after handoff. The same buffer array was being shared across all chunks written, which works ok if that view were only used within the confines of copy_stream, but in this case the chunks were held across more than a single write. Fixes #4903. See #5007 for the Enumerator#next bug.
|
Dupe of 4212. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
This is the root cause of #4903.
Our Enumerator#next does not appear to be waiting for a second all to perform a second iteration. Because it runs in a separate thread, this causes it to execute in parallel with code that received a previous result. Because of the improper sharing of a write buffer in
IOWritableByteChannel,IO.copy_streamto an Enumerator#next-based sink could see a previously-written chunk modified during use.This issue has been reported against Fiber before, but our Fiber implementation appears to be solid lately. This is strong justification for us to finally eliminate the "second Fiber" we have in Enumerator#next and replace it with one based on our actual Fiber.
The text was updated successfully, but these errors were encountered: