Why was Waiter deprecated? #411
nickpoorman
started this conversation in
General
Replies: 1 comment 1 reply
-
IIUC your use case, you can now do this instead: results = []
barrier.wait do |task|
results << task.wait
# Wait for 3 things:
break if results.size >= 3
end
|
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Why was the Waiter deprecated in favor of the Barrier? It seems like there's still a use for Waiter.
In the example below you can see that if I don't explicitly wait for the async tasks to start then it's possible some may not start before stop is executed. Seems like a lot of extra boilerplate that needs to be added to each async task to ensure graceful startup / shutdown.
If we still had Waiter, I could say I know there will be 3 tasks and I want to wait for 3 tasks to finish. By specifying the initial number of tasks up front that I know must start / complete before wait unblocks, I know I'm getting everything started up and shutting down. Without the fixed number up front, there's this subtle bug that all the tasks are not created before stop. I guess I could create a wrapper class to do all this but it seems like a primitive that should be part of the async API.
Or am I thinking about this the wrong way?
Beta Was this translation helpful? Give feedback.
All reactions