-
-
Notifications
You must be signed in to change notification settings - Fork 97
Add a concurrency primitive for waiting for a specific number of tasks to complete. #189
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
Conversation
36fe6f7
to
3c1707f
Compare
3c1707f
to
73b024c
Compare
I'm not sure if the name of this is class is correct. If you only care about waiting for some subset of tasks, this + a semaphore is probably more useful than a barrier. I think they serve different purposes. |
|
For deadline scheduling, it could also be useful: barrier = Async::Barrier.new
waiter = Async::Waiter.new(parent: barrier)
urls.each{|url| waiter.async{... url ...}}
waiter.each(timeout: 5) do
# Process as many completions as possible within 5 seconds
end
barrier.stop # kill all remaining tasks |
|
lib/async/waiter.rb
Outdated
@parent = parent | ||
end | ||
|
||
def async(parent: (@parent or Task.current), &block) |
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.
Why do you prefer or
over ||
here and in other similar places?
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.
|
is bitwise or.
||
is boolean or.
or
is logical/semantic/object or.
That's my mental model. I try to be consistent but I'm not always. I also prefer or
when the lhs and rhs are disjoint and you are only concerned with the semantics "execute this or execute that" vs "result = boolean this || boolean that". I think the goal for me is to communicate that this isn't a boolean result we care about (true or false). The fact that ||
doesn't just convert everything to true/false is odd to me.
I like this implementation and |
See #174 for a slightly different implementation.
@bruno- @zhulik what do you think of this? You can compose it with barrier if you need a final wait-all, which simplifies the implementation and also makes it composable with semaphore, etc.