Back

@DiazCarrete what would be the usecase? Mostly you can't do much with the Async itself, if that is what you mean by handle. But you can easily get the ThreadId (something like myThreadId or such)

@robinp It was an attempt at satisfying these requirements https://discourse.haskell.org/t/dynamic-number-of-asyncs/11574/1 and avoid a potentially unbounded number of nested "withAsync"s https://hackage.haskell.org/package/async-2.2.5/docs/Control-Concurrent-Async.html#v:withAsync

My idea was to keep an explicit collection of outstanding Async handles in a mutable reference, and let each spawned thread remove itself from the collection when it finishes. https://discourse.haskell.org/t/dynamic-number-of-asyncs/11574/8

@DiazCarrete thanks! Didn't read the linked to thing, and don't fully grasp the usecase, so with these in mind - globally limiting counts sound hard (not technically, bit in practical use).

When I'm concerned I use a pool that limits concurrency on a per-usecase (often practically per callsite) basis.

I have since custom light abstraction on that. Was not trivial to make all the masking right so accounting doesn't leak. Might want to publish one day..

@DiazCarrete I think my implementation is a wrapper around the respective ops, and indeed manages some mutable vars. But those are only about counts, not about Async identities. It also has some queueing/ rejection support for shedding.

@DiazCarrete my usecase only needs a horizontal limiting of runaway concurrency. Your nested withAsync case sounds like some recursive deep processing.. which might better need a case-specific structure. For example, use horizontal limiting on the concurrent top level tasks, but then for each task do something specific to limit concurrency.. like pass along depth in recursion and don't go concurrent below certain depth of such