-
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
Do we need to support invoking sync functions? #77
Comments
I'd be in favor of only supporting async functions, for exactly the reasons you describe. I don't think there's anything significant to be gained, but there is additional complexity that could easily be avoided. |
See the comment in richardsheridan/trio-parallel#2 which I think is more fuel for this change. |
Yah, I'm thinking for a |
Yeah so TLDR: is that if we're calling sync funcs in some remote actor you'll need the I also think we should make a alt-projects list in the readme and point to others for this kind of thing. |
We already have a pointer to |
You can always wrap a sync function in an async one and there seems to be no good reason to support invoking them directly especially since cancellation won't work without some thread hackery. If it's requested we'll point users to `trio-parallel`. Resolves #77
You can always wrap a sync function in an async one and there seems to be no good reason to support invoking them directly especially since cancellation won't work without some thread hackery. If it's requested we'll point users to `trio-parallel`. Resolves #77
@jtrakk made a good point in gitter that supporting both async and regular functions for remote invocation is a bit odd and probably unnecessary. I think I agree; there ain't nothing a regular func can do that an async one can't. Unless I'm forgetting something I think it should be fine to just remove support for regular functions?
Off hand it would allow removing the slew of checks in
_actor._invoke()
.The text was updated successfully, but these errors were encountered: