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.

[nateberkopec]

The problem with Idler for my usecase is that I'm not doing something like running a long-running app process which processes a few requests every second. I want to spin up a bunch of fibers for a short period of time to download a bunch of stuff in parallel. I know what that workload is going to be like, but Idler doesn't in advance because it can only observe what has already happened, so by the time it gets "the right answer" as for how much work to let in I may already be done.

Also to use Idler effectively to manage GVL contention between multiple threads, I need one scheduler per process, which as we established in #392 is hard to do.

[ioquatix]

Async::Idler will yield at least once before creating a child task by design so that the load is assessed within at least one cycle of execution. So it won't spin up an uncontrollable amount of work, but it can ramp up quickly. I'd suggest you try it?

If you need to control access to a resource over multiple processes, that falls outside the scope of a purely Async library based solution as this is a more general problem. There are lots of ways to solve it but one way is to use a shared semaphore via a pipe: https://github.com/socketry/async-examples/tree/main/shared-semaphore

As with all things that coordinate across multiple processes, error handling, starvation, etc, become much bigger problems.

[nateberkopec]

Imagine you wanted to run Packages#fetch from inside a thread. You want to download stuff with as much parallelism as you can without unduly hogging the GVL from other threads. WDYD?

[ioquatix]

If it's IO bound it won't be hogging the GVL.