You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Though I'm pretty much entirely against apis of this sort:
because they're imo entirely superfluous and use classes unnecessarily, and
because they're enforcing behind-the-scenes object setup and persistence (that definitely isn't required to get actor behavior) which you don't really need for holding long running state if running trio task functions in separate thread sessions, communicating over our channels,
because most of these systems rely on the futures/promises paradigm which trio explicitly avoids and thus most of why you would want a method-as-callback api is moot,
but, it seems users coming from the actor systems space are confused when they don't see apis of this sort.
Thus, I propose we at least have a (couple) recipe(s) to show how such things can be accomplished.
ray's actors are basically just classes instantiated and persisted in a thread - further I would argue these aren't real actors as in the actor model (they can't spawn other actors [at least obviously] and don't send messages to one another other then through these remote handle api - which is really just a form of proxy api:
they can pass around handles between remotes (which makes sense since the default is to use shared memory threads afaiu) but it seems there are limitations cross-process where you have to use named actors as we would expect (you can't hack IPC).
A Ray Actor is also a “Ray worker” but is instantiated at runtime (upon actor_cls.remote()). All of its methods will run on the same process, using the same resources (designated when defining the Actor). Note that unlike tasks, the python processes that runs Ray Actors are not reused and will be terminated when the Actor is deleted.
In other words, they seem to think having a "persistent class" makes something an "actor" for some reason, when really their "workers running tasks" are more likely to viewed as the "actors" from actor model theory.
Though I'm pretty much entirely against apis of this sort:
trio
task functions in separate thread sessions, communicating over our channels,trio
explicitly avoids and thus most of why you would want a method-as-callback api is moot,but, it seems users coming from the actor systems space are confused when they don't see apis of this sort.
Thus, I propose we at least have a (couple) recipe(s) to show how such things can be accomplished.
#190 is one effort on this front for @fjarri.
Some examples from the mentioned projects:
ray
's actors are basically just classes instantiated and persisted in a thread - further I would argue these aren't real actors as in the actor model (they can't spawn other actors [at least obviously] and don't send messages to one another other then through theseremote
handle api - which is really just a form of proxy api:pykka
has a similar api but they actually have explicit message passing and call a remote handle api for what is is, a proxyWe have wanted a proxy style wrapping for a few things in
piker
which is shown in small degrees in #190.I would be interested to hear more opinions and complaints in this arena.
The text was updated successfully, but these errors were encountered: