How to avoid leaking threads?

[NicolasT]

How to prevent threads from leaking with async. Should we consider ki to solve this issue? Are the actors supposed to be single threaded?

Raised by @TristanCacqueray in https://discourse.haskell.org/t/towards-an-actor-framework-for-haskell/5929/10, based on the content of https://github.com/NicolasT/troupe/wiki/Design-Ideas/.

[NicolasT]

Indeed, async by itself doesn't prevent threads leaking. However, its link feature does, though this can't be used as-is in this project: Erlang provides, next to the ability to (bidirectionally) link two processes also an unlink call to undo this, and async doesn't allow unlinking.

Can ki be used? I don't believe so, at least not obviously. On one hand, Erlang's spawn doesn't impose any kind of linking. So, it is possible to create a process whose lifetime is not at all bound by the lifetime of the process calling spawn.

Furthermore, linked processes can request not to be killed when a linked peer dies, but instead receive a message notifying about this, and hence outliving the linked peer. This is core to how supervisors are implemented, for example. It's quite unclear how to model this in a Ki scope.

Next to this, a supervisor has specific (configurable) behaviour w.r.t. ordering when it stops and stops supervised processes. Using a simple Ki Scope would not allow for this.

Basically: yes, there are ways to spawn processes and leak them. Though if you use higher-level constructs (like supervisors), this won't happen. Similar to how async can leak a thread, but you're supposed to use withAsync and similar for safety.

[NicolasT]

Are the actors supposed to be single threaded?

Yes, Erlang-style. ProcessM would almost necessarily be MonadIO to do something useful, so yeah someone could liftIO (forkIO ...), but... 🤷‍♂️

[TristanCacqueray]

If the root process starts with a Ki Scope, it can pass it to the child scope so that they can spawn thread outside of their local scope. I guess the main benefit is to offload threads management to an external library that guarantees the absence of leak.

Though I can't tell if this usage is well supported by ki, and killing a scope is a bit awkward according to awkward-squad/ki#12 .

Maybe a troupe-ki package could be provided to create leak-free multi-threaded actor with a Ki Scope?

[NicolasT]

Running the "root" process with some Ki scope and then ensure all spawned threads are in said scope could indeed help to ensure no threads are left running when the "root" process exits. However, I don't believe that's how the Erlang VM works: there, I don't think there's really some "root" process, and the runtime keeps running as long as there are schedulable processes.

A halt equivalent could, I guess, be implemented this way: have some "root" process (with a Ki Scope) which blocks on an MVar (or equivalent), and halt simply filling said MVar.

Similarly, a supervisor implementation could use Ki and a Scope to ensure any process it spawns gets killed when the supervisor exits. However, this would only be a fail-safe in case of implementation bugs, as in, a supervisor is supposed to clean up everything first anyway before it exits.

[NicolasT]

So, there may be a place for using ki even in the core library, but I don't think we can say for sure right now 😃

[NicolasT]

Oh, forgot to mention. From my reading, it appears Erlang actually uses a (runtime-provided) process that's responsible for spawning new processes. So as you point out, one possibility is threading a Scope so it can be used wherever necessary. Another is to build the runtime of this library such that it also uses a process to spawn new processes, at which point this could use a scope.

However, it has one drawback: it may imply death of the process-spawner process would kill all spawned processes, which is not the intent, instead, we'll want to supervise the process-spawning process and restart it when necessary.

[HoraceDugmorea8h]

When working with asynchronous programming, it's important to properly manage the lifecycle of threads to prevent leaks. One approach is to use a thread pool with a maximum number of threads, and to reuse threads from the pool instead of creating new ones. Another option is to use a garbage collector to automatically reclaim unused threads. As for actors, they are typically designed to be single-threaded, with each actor running in its own thread or process. This helps to simplify concurrency management and avoid race conditions.

[SimonaKempleG7]

Yes, managing thread lifecycle is important in asynchronous programming to prevent leaks. Using a thread pool or a garbage collector can help ensure proper management of threads. Actors are typically designed to be single-threaded to simplify concurrency management and avoid race conditions. Each actor runs in its own thread or process.

[mitchellwrosen]

I'd like to chime in here and say that ki indeed may not be straightforwardly applicable to a different sort of concurrency architecture than bog-standard structured concurrency. However, feel free to steal bits and bobs of its implementation at your discretion. And, as you mention @NicolasT, some internal usage of ki just to catch implementation bugs in supervisors and whatnot may be worthwhile, if only temporarily.

[NicolasT]

Thanks for weighing in, much appreciated!

I have some code in #7 implementing the basic primitives, using STM wherever possible (with lots of room for optimization/improvement). One part I'm not overly happy with, and it's indeed thread management, mainly related to exception handling: when spawning a new Process, I fire off an Async which, internally, then uses withAsync to wait for the Process to complete (successfully, or with some exception), and throwTos an exception into it when needed (e.g., when a linked process died). Once completed, it'll deliver whichever signals (exceptions) and messages it needs to based on processes linked to or monitoring the managed process.

However, this monitor could fail, I guess, either due to some synchronous exception (this would be an implementation bug), or an asynchronous exception. Hence, I figure things should be masked, maybe even uninterruptibleMasked, to make sure that, if the monitor gets killed (and takes the Process thread with it), all linked processes or monitors are notified anyway.