Confused about the concept of parents

[nateberkopec]

The docs example in Best Practices says:

require 'async'
require 'async/barrier'
require 'async/semaphore'

class Packages
	def initialize(urls)
		@urls = urls
	end
	
	def fetch
		barrier = Async::Barrier.new

		Sync do
			# Only 10 tasks are created at a time:
			semaphore = Async::Semaphore.new(10, parent: barrier)
			
			@urls.map do |url|
				semaphore.async do
					fetch(url)
				end
			end.map(&:wait)
		ensure
			barrier.stop
		end
	end
end

Why is the parent the barrier, and not the semaphore? Can it be the other way around? Why? It seems like it works the other way round too?

[ioquatix]

In this example, the Async::Semaphore is given the Async::Barrier as its parent, which means any tasks created by the semaphore are also tracked by the barrier. The barrier provides lifecycle management: it can wait for or stop all child tasks, regardless of how they were spawned. While in principle you can do it either way, I think it usually makes more sense to have a barrier as parent.

Why parent: barrier?

This ensures that all tasks created through the semaphore are children of the barrier. At the end of the fetch method, the call to barrier.stop ensures that any still-running tasks are cancelled. It acts as a cleanup scope for the whole batch of asynchronous work.

Can it be the other way around?

If you reversed the relationship and made the barrier a child of the semaphore, the code will still work. However:

• The semaphore would only track its own tasks.
• The barrier wouldn't include any tasks unless they were explicitly made its children.
• Calling barrier.stop would have no effect on the tasks created directly in the semaphore, because they wouldn’t be known about by the barrier.

So yes, it might work—but barrier.stop might not do what you expect if you were also executing tasks directly by the semaphore.

How to think about a barrier and semaphore

When you have an unbounded number of tasks at run-time, you need some mechanism to coordinate their execution. A barrier provides a mechanism to coordinate those tasks, both in terms of grouping them, waiting on them, and stopping them.

A semaphore is a mechanism to constrict entry into the barrier.

Semaphores are hard

I’m not a fan of magic numbers in systems, and semaphores often require exactly that. Limiting concurrency with Async::Semaphore.new(10) begs the question: why 10? Why not 5 or 50? The answer is usually vague and workload-dependent. This kind of tuning is fragile and often doesn’t generalize well.

Instead, I recommend using Async::Idler.

Async::Idler automatically adapts to the runtime load. It monitors event loop saturation and controls task spawning to maintain a target utilization (by default, 80%). That means you get fair and efficient task scheduling without needing to guess how many tasks is “too many.” This is especially useful for IO-heavy workloads like fetching URLs in parallel.

If you're trying to avoid overwhelming your system or introducing latency due to event loop congestion, Async::Idler gives you a principled and adaptive alternative.