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

SPD-410: stop functionality #16

Merged
merged 36 commits into from
Sep 17, 2024
Merged

SPD-410: stop functionality #16

merged 36 commits into from
Sep 17, 2024

Conversation

lnauta
Copy link
Member

@lnauta lnauta commented Jul 30, 2024

The functionality described in SPD-410 is added including tests and docstrings. Please review and let me know if theres anything missing.

lnauta added 12 commits July 19, 2024 15:51
The stop logic should be under user control. By putting it in a
method its more easily accessible, instead of changing the template
class in the example folder.

The downside is that the EndlessViewIterator goes into a while loop
whichs needs to be broken. As the logic in the run method is one
level higher, its passed into the EVI if its being used. The while
loop can get broken and stop the iterator after the stop condition is
reached.

The flow goes as follows:
EVI.__next__ is called when the iterator is empty
try: EVI.next calls the ViewIterator.next
which calls TaskViewIterator.__next__
which calls TaskViewIterator.claim_task
which calls _claim_task which fails and
throws a StopIteration at EVI.next
and the while-loop continues.
@lnauta lnauta mentioned this pull request Aug 2, 2024
@natalieda natalieda assigned hailihu and unassigned natalieda Aug 15, 2024
@hailihu
Copy link
Collaborator

hailihu commented Sep 3, 2024

Can you resolve merge conflicts, then I can start reviewing? Thanks.

@lnauta
Copy link
Member Author

lnauta commented Sep 3, 2024

Ready to merge!

Copy link
Collaborator

@hailihu hailihu left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice work! I still need to test it fully, but in the meantime you can have a look already at the suggestions/comments.

picas/actors.py Outdated Show resolved Hide resolved
picas/actors.py Show resolved Hide resolved
picas/actors.py Show resolved Hide resolved
picas/actors.py Outdated Show resolved Hide resolved
picas/executers.py Outdated Show resolved Hide resolved
examples/local-example.py Show resolved Hide resolved
picas/actors.py Show resolved Hide resolved
@lnauta
Copy link
Member Author

lnauta commented Sep 4, 2024

Generally on the backwards compatibility:
I went for the design of
RunActor -> RunActorWithStop with the intention of eventually adding an abstract class as:
AbstractRunActor -> RunActor -> RunActorWithStop

We can change this into
AbstractRunActor (= current RunActor) -> RunActor (= current RunActorWithStop)
Where the abstraction will be done later, so its not really an Abstract.

Will that work?

@hailihu
Copy link
Collaborator

hailihu commented Sep 4, 2024

Concerning AbstractRunActor, I don't understand the need of making an abstract class.

@hailihu
Copy link
Collaborator

hailihu commented Sep 4, 2024

I tested user stories 2 (max execution time) and 3 (max no of tokens), but not user story 1 (max queue time) as that requires a long time. I assume this is sufficiently tested by test_signal_handling. Seems to work well!

@natalieda can you also review to see if I haven't missed anything?

@lnauta
Copy link
Member Author

lnauta commented Sep 5, 2024

Concerning AbstractRunActor, I don't understand the need of making an abstract class.

The prepare and cleanup methods already show signs that we may want an ABC, but indeed it's not strictly necessary.
We can also call it BaseRunActor, or something similar.

@hailihu
Copy link
Collaborator

hailihu commented Sep 5, 2024

Concerning AbstractRunActor, I don't understand the need of making an abstract class.

The prepare and cleanup methods already show signs that we may want an ABC, but indeed it's not strictly necessary. We can also call it BaseRunActor, or something similar.

I see, in that case I agree with your previously mentioned option:
AbstractRunActor (= current RunActor) -> RunActor (= current RunActorWithStop)
to reduce the changes experienced by users.

tests/test_mock.py Outdated Show resolved Hide resolved
examples/local-example.py Show resolved Hide resolved
@hailihu hailihu self-requested a review September 16, 2024 08:56
@hailihu
Copy link
Collaborator

hailihu commented Sep 16, 2024

After commit 610f99d, testing with python local-example.py fails. Requested changes below fix some bugs introduced since that commit.

examples/local-example.py Outdated Show resolved Hide resolved
examples/local-example.py Outdated Show resolved Hide resolved
picas/executers.py Outdated Show resolved Hide resolved
lnauta and others added 4 commits September 16, 2024 11:26
Co-authored-by: Haili Hu <hailihu@gmail.com>
Co-authored-by: Haili Hu <hailihu@gmail.com>
Co-authored-by: Haili Hu <hailihu@gmail.com>
@natalieda natalieda merged commit f9577d8 into master Sep 17, 2024
4 checks passed
@hailihu hailihu deleted the SPD-410 branch October 9, 2024 07:45
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants