Stopping contexts #18
Labels
enhancement
New feature or request
Comments
Merged
aecay
added a commit
that referenced
this issue
Aug 5, 2019
- remove the should_stop_func argument from __init__ (see #18), and the should_stop property - rename self._send to self._send_fn. Having both self.send and self._send was too confusing - Refactor the context managers to use contextlib.asynccontextmanager. This makes the code much shorter and more intelligible
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
We used to have an attribute called
should_stop_funconContextobjects. In the original implementation, this was always identical to theshould_stopof theRunnerthat created the context. It was removed for being vestigial in #15.However, we might want to bring this functionality back. To do so properly, as @jb098 pointed out, we should add a settable property to context objects, which journey functions can manipulate.
My question that I think I would need to understand to implement this properly is: what does it mean when a journey stops its context? Should some resources be released? Does the runner need to react in any way? Should it behave differently in any way from just returning from the journey fn and letting the GC take care of the context object?
The text was updated successfully, but these errors were encountered: