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
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.
fabian2k|6 months ago
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.