-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Interpreter: fix fiber's resumable property #14252
Interpreter: fix fiber's resumable property #14252
Conversation
Fibers in the interpreted code are backed by real fibers run by the interpreter. The fiber context is thus fake in the interpreted code, and the resumable property should directly target the real fiber's context. Also explains why we call `Fiber#resume`.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is it possible to have a test that should break in the current HEAD but work with this patch?
The spec fails with the interpreter for the current crystal (1.11), but succeeds with this patch (or when compiled with any older version).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nitpick
@beta-ziliani I just added a test. It fails with the interpreter of crystal 1.11 but succeeds otherwise (this patch, or when compiled). |
Co-authored-by: Sijawusz Pur Rahnama <sija@sija.pl>
Co-authored-by: Johannes Müller <straightshoota@gmail.com>
The
resumable
property of fiber contexts was wrong in interpreted code: it was never reset to0
.This patch lets the interpreted fiber read the resumable property of the interpreter's fiber (the real one) though a new primitive. The interpreter is now responsible from reporting the value properly. This avoids having to manipulate
resumable
in the interpreted code, and allows to act on the actual state.Alternative: the interpreter could set the
resumable
properties of the fibers in theinterpreter_swapcontext
primitive, it would be fake but probably not critical (the interpreter's scheduler would still act on the real property), but we don't have references back into the interpreted fibers (we could add it when interpreted) + I don't know how the interpreter updates values into an interpreted type (I could learn).