Hacker News new | ask | show | jobs
by fabian2k 301 days ago
This seems to be a thin abstraction over Channels, I'd probably prefer to use Channels directly in almost all cases.

I really like Channels for in-memory queues like this, they're very nice and it's easy to make everything parallel. But if you need more than this you usually need persistence, and then you need something else entirely.
1 comments
mikasjp 301 days ago
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.
link
fabian2k 301 days ago
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.
link
mikasjp 301 days ago
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
link
fabian2k 300 days ago
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.

link
moi2388 301 days ago
Oh that sounds pretty darn nice actually
link