Add a concurrency primitive for waiting for a specific number of tasks to complete.

[ioquatix]

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.

[ioquatix]

I'm not sure if the name of this is class is correct. Async::Waiter just seems too generic.

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.

[bruno-]

I like this implementation better 👍

Async::Waiter just seems too generic

Yes, and also the first association for waiter is that is should serve something

Maybe Async::Moat?

[ioquatix]

• Async::FinishLine
• Async::Winners
• Async::Deadline
• Async::Goal
• Async::Race (used in JS?)
• Async::Battle
• Async::Butler
• Async::Completions
• Async::LimitedBarrier (similar to Async::LimitedQueue)

[ioquatix]

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

[bruno-]

Async::LimitedBarrier sounds the best IMO.

[zhulik]

Why do you prefer or over || here and in other similar places?

[ioquatix]

| 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.

[zhulik]

I like this implementation and Async::LimitedBarrier seems to be a good name IMO