Skip to content
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

Recipe for "actor class" style stuff like ray and pykka #191

Open
goodboy opened this issue Jan 26, 2021 · 1 comment
Open

Recipe for "actor class" style stuff like ray and pykka #191

goodboy opened this issue Jan 26, 2021 · 1 comment
Labels

Comments

@goodboy
Copy link
Owner

goodboy commented Jan 26, 2021

Though I'm pretty much entirely against apis of this sort:

  1. because they're imo entirely superfluous and use classes unnecessarily, and
  2. 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,
  3. 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.

#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 these remote handle api - which is really just a form of proxy api:
@ray.remote
class Counter(object):
    def __init__(self):
        self.value = 0

    def increment(self):
        self.value += 1
        return self.value

    def get_counter(self):
        return self.value

counter_actor = Counter.remote()
import pykka

class Calculator(pykka.ThreadingActor):
    def __init__(self):
        super().__init__()
        self.last_result = None

    def add(self, a, b=None):
        if b is not None:
            self.last_result = a + b
        else:
            self.last_result += a
        return self.last_result

    def sub(self, a, b=None):
        if b is not None:
            self.last_result = a - b
        else:
            self.last_result -= a
        return self.last_result

actor_ref = Calculator.start()

We 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.

@goodboy goodboy added help wanted Extra attention is needed docs discussion api labels Jan 26, 2021
@goodboy
Copy link
Owner Author

goodboy commented Jan 26, 2021

It's probably worth replicating some of the examples from both of these projects for newcomers to see the trio/tractor way:

Some extra interesting stuff from ray:

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant