Creator here; it's worth pointing out that the current picking solution might suffer from its own (performance, not scalability) problems - it reads the pools info from a shared ETS table and picks a random element from that list; mandatory, deterministic naming of the pools would limit this step to a simple concatenation / conversion to atom. Something I will consider.
Read this in the description: "If you cannot afford to ignore a query and wish to eventually serve every one of them, dispcount might not be for you." Which does not fit my current problems; in any case, it seems to be a very promising project, I had no knowledge of it. Good suggestion.
Hi, creator here; at the time I had encountered the need of concurrently downloading multiple files (of potentially different sizes, at potentially different rates, ..), albeit in a controlled way (whether this bound be 2, 10 or 100 tasks at once.) This issue had popped up before, so I figured I might as well have a generic implementation close by for the future.
I suppose one of the most practical features resides in the fact that it's 'consumer' based - the workers will continue trying to get work done as long as they're free and there are pending tasks (instead of a 'split first' approach, which makes more sense for homogeneous batches.)
I wouldn't use it for small-lived (< 10ms?) tasks, though - the overhead might not be worth it.
I recommend providing a walk through of that example in your README. Would be much more compelling to me than the factorial demo you've written up so far.
It's an opinion piece, not a news article.