Open declanvk opened 6 years ago
Nice write-up @declanvk 👍
I've moved the write-up above to a HackMD file (just sign in with your GitHub account) that we can all edit for questions/clarifications/etc. I've taken your text and formatted it for easier scanning.
@ellisonbg @willingc This is a brain dump of the various ways that the kernel should work, but may not currently uphold. I've attempted to define any terms that are important and remove ambiguity. I will continue adding to this issue, as this single comment is not complete record of the things the kernel does.
Definitions/Notes
request
- is a message from the front end, usuallyexecute_request
, that contains some metadata and a string containing code to be executed by the kernel.input variables
- variables from the code block of therequest
that are not assigned to within the block of code from therequest
. In this context "assigned to" also covers class or function definition, anything that associates a name with an object. The assumption of the kernel is that any variable that is reference but not assigned within this code block, must have been assigned in another code block, sent in a previous request.output variable(s)
- variables from the code block of therequest
that are assigned to within the block of code from therequest
.namespace
- dictionary that holds the values of variable, mapping names of variables to values of variables.asyncio.sleep(0)
- this coroutine is used to return control to the event loop and increase the number of points in the execution where otherrequest
/other computation can be interleaved. Returning control to the event loop in more places increases the appearance of parallel execution, even when all code in the event loop is running in a single thread.execution context
- this object will run code string and capture any output in the form of stdout, stderr, exception, etc. In the case of a single assignment as the last expression in the code block, the AST will be manipulated such that the displayhook will capture the value of the last assignment. Theexecution context
will return a container object that holds all the different forms of output.Lifecycle of a Non-Awaitable, Non-Generator Request
request
, and extractinput variables
andoutput variable(s)
from the code string in the request.input variables
from the old definition to the new definition. Then update the dependency graph with the compute difference. b. If it is a new definition, create a new node in the dependency graph, then add all the edges representing theinput variables
output variable(s)
, even if there are none due to it being a new definition._repr_html_
,_repr_svg_
, etc.output variable(s)
repeat steps 4 & 5 with the descendant's block of code.request
.Lifecycle of a Awaitable, Non-generator Request
Steps 1-3 are the same as they are for Non-Awaitable, Non-Generator Requests.
output variable(s)
. Then await the value of theoutput variable(s)
, because it is a coroutine, and the update theexecution context
'snamespace
with the value of the awaited variable.Steps 5-8 are the same as they are for Non-Awaitable, Non-Generator Requests.
Lifecycle of a (Async) Generator Request.
Steps 1-3 are the same as they are for Non-Awaitable, Non-Generator Requests.
output variable(s)
. Detect if this value is a regular generator or an async generator. a. If the value is a regular generator, then convert it to an async generator that will yield its values and sleep a tiny amount between each time. b. if the value is an async generator, do nothing.output variable(s)
as the current one.namespace
of theexecution context
._repr_html_
,_repr_svg_
, etc.output variable(s)
repeat steps 4-7 with the descendant's block of code.