-
Notifications
You must be signed in to change notification settings - Fork 6k
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
[Utils] [CORE-658] ray.util.Queue Empty and Full exceptions extend queue.Empty and Full #50261
Conversation
to match what multiprocessing.Queue does to simplify client exception handling Signed-off-by: Ibrahim Rabbani <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall looks good to me! Just a minor process question.
|
||
import ray | ||
from ray.util.annotations import PublicAPI | ||
|
||
|
||
@PublicAPI(stability="beta") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As it is marked as beta, I'm wondering if we should follow the deprecation period mentioned here: https://docs.ray.io/en/latest/ray-contribute/stability.html#beta
cc: @jjyao
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense. I think after Jiajun's comment, I'm going to make the change backwards compatible.
|
||
import ray | ||
from ray.util.annotations import PublicAPI | ||
|
||
|
||
@PublicAPI(stability="beta") | ||
class Empty(Exception): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For backward compatibility, can we make the current Empty
and Full
the subclass of python Empty and Full?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Made the change backwards compatible. Would any of the integration tests have caught this backwards incompatible change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably we can add a test in python/ray/tests/test_queue.py
to validate that the queue will through the expected type of Empty
object in the empty scenario.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Unless I'm misunderstanding, python/ray/tests/test_queue.py
already checks for both Empty and Full exceptions.
I was wondering if there's an API-level spec file or protocol definition that ensures backwards compatibility and disallows incompatible changes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense for the test part.
For the API spec, I think the annotation is the only thing that we have for now. cc: @jjyao in case you have more context.
compatibility Signed-off-by: Ibrahim Rabbani <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
Thanks for doing this!! 🎉 |
Simplify ray.util.Queue usage and exception handling by extending queue.Empty and queue.Full.
Closes #50154