-
Notifications
You must be signed in to change notification settings - Fork 107
[hyperactor] remove new from actor
#1962
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
Open
mariusae
wants to merge
13
commits into
gh/mariusae/139/base
Choose a base branch
from
gh/mariusae/139/head
base: gh/mariusae/139/base
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We shouldn't mandate how an actor is actually instantiated. Rather, 'spawn' should just take over ownership of an `Actor` object directly, and run its loop from there. This helps to separate concerns and simplify the implementation. In this change:
1) We remote `new` from `Actor`, and only require it in `RemoteSpawn` (renamed from `RemotableActor`), in order to enable remote spawning
2) Change the spawn APIs to take ownership over an actor object
3) Remote the `derive(Actor)` macro, this can now be implemented with a simple `impl Actor for Foo{}` marker trait when no additonal behavior needs to be customized.
4) Simplify a bunch of actor construction, esp. in tests, where we like to just use simple objects.
Using this, in the next change, we will make `spawn` fully synchronous.
This leaves the #[export] attribute macro somewhat schizophrenic: `spawn = true` now only registers the actor in the remote registry. We should think about how to simplify this, too.
Differential Revision: [D87575629](https://our.internmc.facebook.com/intern/diff/D87575629/)
**NOTE FOR REVIEWERS**: This PR has internal Meta-specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D87575629/)!
[ghstack-poisoned]
mariusae
added a commit
that referenced
this pull request
Nov 20, 2025
We shouldn't mandate how an actor is actually instantiated. Rather, 'spawn' should just take over ownership of an `Actor` object directly, and run its loop from there. This helps to separate concerns and simplify the implementation. In this change:
1) We remote `new` from `Actor`, and only require it in `RemoteSpawn` (renamed from `RemotableActor`), in order to enable remote spawning
2) Change the spawn APIs to take ownership over an actor object
3) Remote the `derive(Actor)` macro, this can now be implemented with a simple `impl Actor for Foo{}` marker trait when no additonal behavior needs to be customized.
4) Simplify a bunch of actor construction, esp. in tests, where we like to just use simple objects.
Using this, in the next change, we will make `spawn` fully synchronous.
This leaves the #[export] attribute macro somewhat schizophrenic: `spawn = true` now only registers the actor in the remote registry. We should think about how to simplify this, too.
Differential Revision: [D87575629](https://our.internmc.facebook.com/intern/diff/D87575629/)
**NOTE FOR REVIEWERS**: This PR has internal Meta-specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D87575629/)!
ghstack-source-id: 324832305
Pull Request resolved: #1962
We shouldn't mandate how an actor is actually instantiated. Rather, 'spawn' should just take over ownership of an `Actor` object directly, and run its loop from there. This helps to separate concerns and simplify the implementation. In this change:
1) We remote `new` from `Actor`, and only require it in `RemoteSpawn` (renamed from `RemotableActor`), in order to enable remote spawning
2) Change the spawn APIs to take ownership over an actor object
3) Remote the `derive(Actor)` macro, this can now be implemented with a simple `impl Actor for Foo{}` marker trait when no additonal behavior needs to be customized.
4) Simplify a bunch of actor construction, esp. in tests, where we like to just use simple objects.
Using this, in the next change, we will make `spawn` fully synchronous.
This leaves the #[export] attribute macro somewhat schizophrenic: `spawn = true` now only registers the actor in the remote registry. We should think about how to simplify this, too.
Differential Revision: [D87575629](https://our.internmc.facebook.com/intern/diff/D87575629/)
**NOTE FOR REVIEWERS**: This PR has internal Meta-specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D87575629/)!
[ghstack-poisoned]
mariusae
added a commit
that referenced
this pull request
Nov 21, 2025
Pull Request resolved: #1962 We shouldn't mandate how an actor is actually instantiated. Rather, 'spawn' should just take over ownership of an `Actor` object directly, and run its loop from there. This helps to separate concerns and simplify the implementation. In this change: 1) We remote `new` from `Actor`, and only require it in `RemoteSpawn` (renamed from `RemotableActor`), in order to enable remote spawning 2) Change the spawn APIs to take ownership over an actor object 3) Remote the `derive(Actor)` macro, this can now be implemented with a simple `impl Actor for Foo{}` marker trait when no additonal behavior needs to be customized. 4) Simplify a bunch of actor construction, esp. in tests, where we like to just use simple objects. Using this, in the next change, we will make `spawn` fully synchronous. This leaves the #[export] attribute macro somewhat schizophrenic: `spawn = true` now only registers the actor in the remote registry. We should think about how to simplify this, too. ghstack-source-id: 324884139 @exported-using-ghexport Differential Revision: [D87575629](https://our.internmc.facebook.com/intern/diff/D87575629/) **NOTE FOR REVIEWERS**: This PR has internal Meta-specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D87575629/)!
We shouldn't mandate how an actor is actually instantiated. Rather, 'spawn' should just take over ownership of an `Actor` object directly, and run its loop from there. This helps to separate concerns and simplify the implementation. In this change:
1) We remote `new` from `Actor`, and only require it in `RemoteSpawn` (renamed from `RemotableActor`), in order to enable remote spawning
2) Change the spawn APIs to take ownership over an actor object
3) Remote the `derive(Actor)` macro, this can now be implemented with a simple `impl Actor for Foo{}` marker trait when no additonal behavior needs to be customized.
4) Simplify a bunch of actor construction, esp. in tests, where we like to just use simple objects.
Using this, in the next change, we will make `spawn` fully synchronous.
This leaves the #[export] attribute macro somewhat schizophrenic: `spawn = true` now only registers the actor in the remote registry. We should think about how to simplify this, too.
Differential Revision: [D87575629](https://our.internmc.facebook.com/intern/diff/D87575629/)
**NOTE FOR REVIEWERS**: This PR has internal Meta-specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D87575629/)!
[ghstack-poisoned]
We shouldn't mandate how an actor is actually instantiated. Rather, 'spawn' should just take over ownership of an `Actor` object directly, and run its loop from there. This helps to separate concerns and simplify the implementation. In this change:
1) We remote `new` from `Actor`, and only require it in `RemoteSpawn` (renamed from `RemotableActor`), in order to enable remote spawning
2) Change the spawn APIs to take ownership over an actor object
3) Remote the `derive(Actor)` macro, this can now be implemented with a simple `impl Actor for Foo{}` marker trait when no additonal behavior needs to be customized.
4) Simplify a bunch of actor construction, esp. in tests, where we like to just use simple objects.
Using this, in the next change, we will make `spawn` fully synchronous.
This leaves the #[export] attribute macro somewhat schizophrenic: `spawn = true` now only registers the actor in the remote registry. We should think about how to simplify this, too.
Differential Revision: [D87575629](https://our.internmc.facebook.com/intern/diff/D87575629/)
**NOTE FOR REVIEWERS**: This PR has internal Meta-specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D87575629/)!
[ghstack-poisoned]
We shouldn't mandate how an actor is actually instantiated. Rather, 'spawn' should just take over ownership of an `Actor` object directly, and run its loop from there. This helps to separate concerns and simplify the implementation. In this change:
1) We remote `new` from `Actor`, and only require it in `RemoteSpawn` (renamed from `RemotableActor`), in order to enable remote spawning
2) Change the spawn APIs to take ownership over an actor object
3) Remote the `derive(Actor)` macro, this can now be implemented with a simple `impl Actor for Foo{}` marker trait when no additonal behavior needs to be customized.
4) Simplify a bunch of actor construction, esp. in tests, where we like to just use simple objects.
Using this, in the next change, we will make `spawn` fully synchronous.
This leaves the #[export] attribute macro somewhat schizophrenic: `spawn = true` now only registers the actor in the remote registry. We should think about how to simplify this, too.
Differential Revision: [D87575629](https://our.internmc.facebook.com/intern/diff/D87575629/)
**NOTE FOR REVIEWERS**: This PR has internal Meta-specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D87575629/)!
[ghstack-poisoned]
We shouldn't mandate how an actor is actually instantiated. Rather, 'spawn' should just take over ownership of an `Actor` object directly, and run its loop from there. This helps to separate concerns and simplify the implementation. In this change:
1) We remote `new` from `Actor`, and only require it in `RemoteSpawn` (renamed from `RemotableActor`), in order to enable remote spawning
2) Change the spawn APIs to take ownership over an actor object
3) Remote the `derive(Actor)` macro, this can now be implemented with a simple `impl Actor for Foo{}` marker trait when no additonal behavior needs to be customized.
4) Simplify a bunch of actor construction, esp. in tests, where we like to just use simple objects.
Using this, in the next change, we will make `spawn` fully synchronous.
This leaves the #[export] attribute macro somewhat schizophrenic: `spawn = true` now only registers the actor in the remote registry. We should think about how to simplify this, too.
Differential Revision: [D87575629](https://our.internmc.facebook.com/intern/diff/D87575629/)
**NOTE FOR REVIEWERS**: This PR has internal Meta-specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D87575629/)!
[ghstack-poisoned]
We shouldn't mandate how an actor is actually instantiated. Rather, 'spawn' should just take over ownership of an `Actor` object directly, and run its loop from there. This helps to separate concerns and simplify the implementation. In this change:
1) We remote `new` from `Actor`, and only require it in `RemoteSpawn` (renamed from `RemotableActor`), in order to enable remote spawning
2) Change the spawn APIs to take ownership over an actor object
3) Remote the `derive(Actor)` macro, this can now be implemented with a simple `impl Actor for Foo{}` marker trait when no additonal behavior needs to be customized.
4) Simplify a bunch of actor construction, esp. in tests, where we like to just use simple objects.
Using this, in the next change, we will make `spawn` fully synchronous.
This leaves the #[export] attribute macro somewhat schizophrenic: `spawn = true` now only registers the actor in the remote registry. We should think about how to simplify this, too.
Differential Revision: [D87575629](https://our.internmc.facebook.com/intern/diff/D87575629/)
**NOTE FOR REVIEWERS**: This PR has internal Meta-specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D87575629/)!
[ghstack-poisoned]
We shouldn't mandate how an actor is actually instantiated. Rather, 'spawn' should just take over ownership of an `Actor` object directly, and run its loop from there. This helps to separate concerns and simplify the implementation. In this change:
1) We remote `new` from `Actor`, and only require it in `RemoteSpawn` (renamed from `RemotableActor`), in order to enable remote spawning
2) Change the spawn APIs to take ownership over an actor object
3) Remote the `derive(Actor)` macro, this can now be implemented with a simple `impl Actor for Foo{}` marker trait when no additonal behavior needs to be customized.
4) Simplify a bunch of actor construction, esp. in tests, where we like to just use simple objects.
Using this, in the next change, we will make `spawn` fully synchronous.
This leaves the #[export] attribute macro somewhat schizophrenic: `spawn = true` now only registers the actor in the remote registry. We should think about how to simplify this, too.
Differential Revision: [D87575629](https://our.internmc.facebook.com/intern/diff/D87575629/)
**NOTE FOR REVIEWERS**: This PR has internal Meta-specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D87575629/)!
[ghstack-poisoned]
We shouldn't mandate how an actor is actually instantiated. Rather, 'spawn' should just take over ownership of an `Actor` object directly, and run its loop from there. This helps to separate concerns and simplify the implementation. In this change:
1) We remote `new` from `Actor`, and only require it in `RemoteSpawn` (renamed from `RemotableActor`), in order to enable remote spawning
2) Change the spawn APIs to take ownership over an actor object
3) Remote the `derive(Actor)` macro, this can now be implemented with a simple `impl Actor for Foo{}` marker trait when no additonal behavior needs to be customized.
4) Simplify a bunch of actor construction, esp. in tests, where we like to just use simple objects.
Using this, in the next change, we will make `spawn` fully synchronous.
This leaves the #[export] attribute macro somewhat schizophrenic: `spawn = true` now only registers the actor in the remote registry. We should think about how to simplify this, too.
Differential Revision: [D87575629](https://our.internmc.facebook.com/intern/diff/D87575629/)
**NOTE FOR REVIEWERS**: This PR has internal Meta-specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D87575629/)!
[ghstack-poisoned]
We shouldn't mandate how an actor is actually instantiated. Rather, 'spawn' should just take over ownership of an `Actor` object directly, and run its loop from there. This helps to separate concerns and simplify the implementation. In this change:
1) We remote `new` from `Actor`, and only require it in `RemoteSpawn` (renamed from `RemotableActor`), in order to enable remote spawning
2) Change the spawn APIs to take ownership over an actor object
3) Remote the `derive(Actor)` macro, this can now be implemented with a simple `impl Actor for Foo{}` marker trait when no additonal behavior needs to be customized.
4) Simplify a bunch of actor construction, esp. in tests, where we like to just use simple objects.
Using this, in the next change, we will make `spawn` fully synchronous.
This leaves the #[export] attribute macro somewhat schizophrenic: `spawn = true` now only registers the actor in the remote registry. We should think about how to simplify this, too.
Differential Revision: [D87575629](https://our.internmc.facebook.com/intern/diff/D87575629/)
**NOTE FOR REVIEWERS**: This PR has internal Meta-specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D87575629/)!
[ghstack-poisoned]
We shouldn't mandate how an actor is actually instantiated. Rather, 'spawn' should just take over ownership of an `Actor` object directly, and run its loop from there. This helps to separate concerns and simplify the implementation. In this change:
1) We remote `new` from `Actor`, and only require it in `RemoteSpawn` (renamed from `RemotableActor`), in order to enable remote spawning
2) Change the spawn APIs to take ownership over an actor object
3) Remote the `derive(Actor)` macro, this can now be implemented with a simple `impl Actor for Foo{}` marker trait when no additonal behavior needs to be customized.
4) Simplify a bunch of actor construction, esp. in tests, where we like to just use simple objects.
Using this, in the next change, we will make `spawn` fully synchronous.
This leaves the #[export] attribute macro somewhat schizophrenic: `spawn = true` now only registers the actor in the remote registry. We should think about how to simplify this, too.
Differential Revision: [D87575629](https://our.internmc.facebook.com/intern/diff/D87575629/)
**NOTE FOR REVIEWERS**: This PR has internal Meta-specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D87575629/)!
[ghstack-poisoned]
We shouldn't mandate how an actor is actually instantiated. Rather, 'spawn' should just take over ownership of an `Actor` object directly, and run its loop from there. This helps to separate concerns and simplify the implementation. In this change:
1) We remote `new` from `Actor`, and only require it in `RemoteSpawn` (renamed from `RemotableActor`), in order to enable remote spawning
2) Change the spawn APIs to take ownership over an actor object
3) Remote the `derive(Actor)` macro, this can now be implemented with a simple `impl Actor for Foo{}` marker trait when no additonal behavior needs to be customized.
4) Simplify a bunch of actor construction, esp. in tests, where we like to just use simple objects.
Using this, in the next change, we will make `spawn` fully synchronous.
This leaves the #[export] attribute macro somewhat schizophrenic: `spawn = true` now only registers the actor in the remote registry. We should think about how to simplify this, too.
Differential Revision: [D87575629](https://our.internmc.facebook.com/intern/diff/D87575629/)
**NOTE FOR REVIEWERS**: This PR has internal Meta-specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D87575629/)!
[ghstack-poisoned]
We shouldn't mandate how an actor is actually instantiated. Rather, 'spawn' should just take over ownership of an `Actor` object directly, and run its loop from there. This helps to separate concerns and simplify the implementation. In this change:
1) We remote `new` from `Actor`, and only require it in `RemoteSpawn` (renamed from `RemotableActor`), in order to enable remote spawning
2) Change the spawn APIs to take ownership over an actor object
3) Remote the `derive(Actor)` macro, this can now be implemented with a simple `impl Actor for Foo{}` marker trait when no additonal behavior needs to be customized.
4) Simplify a bunch of actor construction, esp. in tests, where we like to just use simple objects.
Using this, in the next change, we will make `spawn` fully synchronous.
This leaves the #[export] attribute macro somewhat schizophrenic: `spawn = true` now only registers the actor in the remote registry. We should think about how to simplify this, too.
Differential Revision: [D87575629](https://our.internmc.facebook.com/intern/diff/D87575629/)
**NOTE FOR REVIEWERS**: This PR has internal Meta-specific changes or comments, please review them on [Phabricator](https://our.internmc.facebook.com/intern/diff/D87575629/)!
[ghstack-poisoned]
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Stack from ghstack (oldest at bottom):
spawnsync #1968newfrom actor #1962We shouldn't mandate how an actor is actually instantiated. Rather, 'spawn' should just take over ownership of an
Actorobject directly, and run its loop from there. This helps to separate concerns and simplify the implementation. In this change:newfromActor, and only require it inRemoteSpawn(renamed fromRemotableActor), in order to enable remote spawningderive(Actor)macro, this can now be implemented with a simpleimpl Actor for Foo{}marker trait when no additonal behavior needs to be customized.Using this, in the next change, we will make
spawnfully synchronous.This leaves the #[export] attribute macro somewhat schizophrenic:
spawn = truenow only registers the actor in the remote registry. We should think about how to simplify this, too.Differential Revision: D87575629
NOTE FOR REVIEWERS: This PR has internal Meta-specific changes or comments, please review them on Phabricator!