-
Notifications
You must be signed in to change notification settings - Fork 3
Alternative proposal for concurrent.futures support in effectful
#400
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
base: staging-llm
Are you sure you want to change the base?
Conversation
concurrent.futures support in effectful
jfeser
left a comment
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.
I think this looks like it's moving in good directions. The simple API is a good sign.
I don't like the look of release_handler_lock and friends. I'm surprised that nothing in the LLM provider code seems to call it, which suggests that it must be called by users of that code? I definitely don't think we want this to be part of the public API. My suggestion is to leave this extra API out until we have a clear need for it.
| @dataclass(frozen=True) | ||
| class DoneAndNotDoneFutures[T]: | ||
| done: set[Future[T]] | ||
| not_done: set[Future[T]] |
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.
Isn't this defined in the concurrent.futures library? Do we need our own dataclass definition?
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.
it's a namedtuple in the library, I added this dataclass because @defop ... using the namedtuple type was not allowing .done iirc (or there could have been another issue that was causing this to fail and I misdiagnosed the cause)
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.
There shouldn't be a behavioral difference in effectful between the dataclass and the namedtuple for this simple case, so it's probably worth creating a self-contained test that passes with the dataclass and fails with the namedtuple so that we can try to fix it.
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.
Oh yep will do!
Oh, yep, that was enabled by the realisation that |
|
Proposed interface is now: |
In draft mode as it's very WIP, but following discussions with @jfeser, this branch proposes an alternative implementation for async support for effectful through concurrent.futures.