-
Notifications
You must be signed in to change notification settings - Fork 12
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
Add a way to shield a stream's underlying channel #171
Conversation
Add a ``tractor._portal.StreamReceiveChannel.shield_channel()`` context manager which allows for avoiding the closing of an IPC stream's underlying channel for the purposes of task re-spawning. Sometimes you might want to cancel a task consuming a stream but not tear down the IPC between actors (the default). A common use can might be where the task's "setup" work might need to be redone but you want to keep the established portal / channel in tact despite the task restart. Includes a test.
tractor/_portal.py
Outdated
@contextmanager | ||
def shield_channel( | ||
self | ||
) -> typing.AsyncGenerator['StreamReceiveChannel', None]: |
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.
Lol this type sig is obv wrong; originally made it async, for no good reason..
|
||
async with tractor.open_nursery() as n: | ||
|
||
stream = await(await n.run_in_actor( |
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.
Btw, what do y'all think about a ActorNursery.stream_from_actor()
sugar for this pattern?
The portal is feeling a little awkward (too future-y) in the streaming case, but maybe it's just me?
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.
In theory you can actually just call Portal.result()
before returning from .run_in_actor()
but it means each call is then blocking and you'd have to spawn multiple (one-off) actors using tasks. Not sure if this is a problem and maybe will get hashed out with the discussion in #66.
I prefer one of these:
|
Sticking with |
Ok think this is ready finally (after wrangling some tests code along the way). I'll probably merge in the morning if noone pipes up. |
Add a
tractor._portal.StreamReceiveChannel.shield_channel()
context manager which allows for avoiding the closing of an IPC stream's underlying channel for the purposes of task re-spawning.Sometimes you might want to cancel a task consuming a stream but not tear down the IPC
between actors (the default). A common use can might be where the task's "setup" work might need to be redone but you want to keep the established portal / channel in tact despite the task restart.
Includes a test.
I'm still not sure on the name here..
Any opinions @salotz , @guilledk?
Note it's used inside a
with stream.<meth name>
Short list:
.shield_channel()
.shielded_channel()
.shield()
bool
property.shield
you assign manually?.shield_from_close()
.channel_kept_open()
.channel_shielded()
Thoughts appreciated.