Prototype distributed actor handles #1137
Conversation
…lso this is very messy.
| /** The index of the task assigned to this actor. Set to -1 if no task is | ||
| * currently assigned. If the actor process reports back success for the | ||
| * assigned task execution, task_counter should be set to this value. */ | ||
| int64_t assigned_task_counter; | ||
| ActorID assigned_task_handle_id; |
There was a problem hiding this comment.
Can you document this field and explain what it's purpose is?
python/ray/actor.py
Outdated
| """ | ||
| return ActorHandleWrapper( | ||
| actor_handle._ray_actor_id, | ||
| random_actor_handle_id(), # Generate a new handle ID. |
There was a problem hiding this comment.
Do we need a deterministic scheme for generating actor handle IDs?
|
Merged build finished. Test FAILed. |
|
Test FAILed. |
|
Merged build finished. Test FAILed. |
|
Test FAILed. |
|
Merged build finished. Test PASSed. |
|
Test PASSed. |
|
Merged build finished. Test FAILed. |
|
Test FAILed. |
|
Just pushed a commit which should fix the jenkins test. Basically, the PR changed the behavior so that now actor classes are exported to Redis as soon as the actor class is defined (before this happened as soon as the first actor object was instantiated). The problem is that we can only export to Redis as soon as |
|
Merged build finished. Test FAILed. |
|
Test FAILed. |
|
Merged build finished. Test PASSed. |
|
Test PASSed. |
|
Merged build finished. Test PASSed. |
|
Test PASSed. |
stephanie-wang
force-pushed
the
multiple-actor-handles
branch
from
310e8cb to
6cc90b2
Compare
|
Merged build finished. Test PASSed. |
|
Test PASSed. |
|
Merged build finished. Test PASSed. |
|
Test PASSed. |
|
Merged build finished. Test PASSed. |
|
Test PASSed. |
|
Ok, I was going to try to disable defining actor definitions on workers, but I can't currently because of #1146 (doing so breaks hyperparameter search). |
|
Merged build finished. Test PASSed. |
|
Test PASSed. |
Allow a task that creates an actor handle to pass it to another task. The passed handle will get forked, so that tasks that get submitted after the fork will get executed after tasks that were submitted before the fork. Tasks will also be serialized per fork of the actor handle. The actor is garbage-collected when the original handle goes out of scope.
The local scheduler schedules tasks FIFO by submission order, regardless of the actor handle it was submitted by.