-
Notifications
You must be signed in to change notification settings - Fork 5.9k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
[core] Weakref semantics for actor handles retrieved from self or by …
…name (#45699) The distributed ref counting protocol assumes that ObjectRefs and ActorHandles are only ever passed in-band, through task arguments and return values. However, it is possible to get actor handles "out-of-band" through two APIs: - `ray.get_runtime_context().current_actor` returns a handle to the `self` actor - `ray.get_actor` can get an actor handle by name We used to assert that when a task finished, its arguments were still registered in the ref count table. That way, we could return the remaining ref count back to the task's caller. This assertion is too strong and causes crash in the following case: 1. Actor receives a handle to itself through its arguments. 2. Actor gets another handle to itself via `ray.get_runtime_context().current_actor` 3. The handle in step (2) goes out of scope -> ref removed from the ReferenceCounter 4. Actor task finishes -> the handle in its arguments is no longer in the ReferenceCounter -> assertion failure This PR updates ref counting for actors to distinguish between strong refs and weak refs. Strong refs are handles passed via task args and return values from the original handle. These are tracked by the ref counting protocol and will keep the actor alive. Weak refs are handles created from the above cases and are not tracked by the ref counting protocol (doing so would require additional protocols to notify the owner of the new handle). This PR also fixes the related #45704 by not incrementing the self ref count on the actor itself when the actor is first created. ## Related issue number Closes #45704. --------- Signed-off-by: Stephanie Wang <swang@cs.berkeley.edu>
- Loading branch information
1 parent
0e5c79a
commit d729815
Showing
19 changed files
with
301 additions
and
98 deletions.
There are no files selected for viewing
This file contains 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
This file contains 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
This file contains 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
This file contains 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
This file contains 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
This file contains 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
Oops, something went wrong.