Decoupling message passing from process management

[NicolasT]

I wonder if the messaging could be decoupled from the process management. It seems like handling the thread hierarchy and supervision could be useful on its own.

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]

Good question, though if this library is supposed to expose Erlang-style functionality, I'm not sure that's possible. Erlang allows for monitoring a peer for which notifications happen though messages, and a linked process' death could be turned into a message instead of a kill as well through setting the trap_exit process flag.

So, since process exit could result in the need to send messages to notify other processes, I'm not sure how to cleanly separate the two, without too many hacks (like some opaque callbacks :: [IO ()] state).

[TristanCacqueray]

That makes sense, so process signals would use the same mailbox like for regular messages?

[NicolasT]

Not really. I don't believe signals can be messages (and from what I understood, they aren't in Erlang either). The reason is quite simple: nothing forces a process to ever attempt to receive some message, which is the only place where these "signal" messages could then be handled (by the runtime/this library) as well.

Signals are, basically, asynchronous exceptions sent to some process/thread.