[mikasjp]

It is a thin abstraction over Channels, and that’s by design. What it adds is graceful shutdown handling, OpenTelemetry integration, timeout support, and simple configuration. I kept needing those pieces in almost every project, so wrapping them up into a small reusable library felt worthwhile.

[fabian2k]

Out of curiosity, why do you use an explicit semaphore here? I usually used Parallel.ForEachAsync together with ReadAllAsync from the Channel. Avoiding the manual semaphore handling was one of the things I really liked about Channels.

[mikasjp]

I’m not entirely sure what the practical advantage of that approach would be compared to the explicit semaphore, but I’d be happy to learn more. If you think it’s a better solution, you’re more than welcome to open a pull request

[fabian2k]

The entire main loop that queues jobs is then a single ForEachAsync that draws from the channel. And it just works, there are no real mistakes you can make with it.

Semaphores work well of course, as long as you don't make mistakes. Probably not an issue in your current version, but can easily happen if the code is more complex or especially when different developers later modify code like this. For example, you release the semaphore in a different class than the point where you acquire it, which makes this a bit less obvious than I'd like. If any developer later adds code that takes a different path this might break, and those kinds of bugs can be very annoying.

It's not really a problem with a simple case like this, but in general I don't use low-level concurrency primitives if there is a higher-level abstraction I can use that fits my problem.

[moi2388]

Oh that sounds pretty darn nice actually