Why use STM and enforce NFData for message passing?

[NicolasT]

What’s the reason for using STM and NFData for messages passing? Lazy message may be useful too, and transaction could be made optional.

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]

I gave this some thought before writing that wiki page as well, and indeed, there's no particular reason to only allow NFData values to be passed as messages (althought to be 100% compatible with Erlang semantics, I do believe that would be a requirement).

I agree there may be use-cases for lazy messages. However, I do believe the 'most obvious way' to send messages must enforce them to be fully evaluated. It's way too easy to send a message to another process which then forces evaluation in said process, i.e., pushing CPU consumption there, which I think is not as it should be (the sender should pay said price), and secondly, evaluation could fail (error, undefined,...). This failure as well should be handled (by crashing) in the sender process, not the receiving one.

So, I do believe the send call should have an NFData constraint and deepseq the message before passing it on.

There could, of course, be a sendLazy without such constraint, which then comes with a bunch of documented warnings, and send is basically \a -> a `deepseq` sendLazy a or similar.

[NicolasT]

As for STM: using this doesn't really impact the messages being transferred. However, I do believe it's something to use in the implementation to get things "right". As an example, a process setting the trap_exit process option, and a linked process dying "at the same time" should return in a predictable result: either the first one being killed before setProcessOption returns, or it not being killed but definitely getting the notification message of the peer being dead.

If a mailbox can be polled in STM, this means a process' receive is (internally) using STM. It could make sense to expose this somewhat, allowing receive to also select on arbitrary STM actions provided by the application author. This way, integration between code designed around this library with third-party code could be achieved, or the ability to combine Erlang-style message-passing-based application design with other approaches to concurrency, in this case GHC's STM, where this makes sense. Think, e.g., a transactional mnesia.

[ElfriedaVassief]

STM (Software Transactional Memory) and NFData (Normal Form Data) are used for message passing in Haskell because they provide important guarantees and optimizations for concurrent programming.

STM ensures that all memory operations within a transaction either succeed atomically or fail atomically, without any possibility of intermediate states being visible to other threads. This provides a higher level of consistency and avoids issues like race conditions and deadlocks.

NFData ensures that data is fully evaluated to its normal form, which can help avoid performance issues with lazy evaluation in a concurrent setting.

While lazy evaluation and optional transactions may have their uses, they also introduce additional complexity and potential issues that STM and NFData can help avoid. Overall, the use of STM and NFData in message passing provides a solid foundation for safe and efficient concurrent programming in Haskell.

[TristanCacqueray]

Incidentally, after asking this question I had an issue with a lazy bottom crashing the receiver of a TChan, resulting in the wrong behavior, so I think it's good to force NFData :)

For STM, I guess the downside is performance, as benchmarked in https://github.com/jberryman/unagi-chan#performance . Though the benefit may outweigh this overhead.

[NicolasT]

Glad we're aligned 😉

I'm aware of unagi-chan, and the performance comparison with STM-backed queues. I guess time will tell 😃 I'd love us to start with something simple-and-safe/correct, then optimize where useful/necessary. That could be by removing message passing out of STM (if possible). Or maybe by optimizing STM? 😄

[dpwiz]

For me, having an STM procedure to read inbox is a way to have a multi-wait without wrapping everything in Async.race manually.

E.g. A "driver" actor may want to poll its inbox, but also wait for a bunch of external events.
This can be solved with send-only actors attached to a dispatcher, but requires more boilerplate.
unagi-chan has tryReadChan, but STM can be lingua franca for event providers without extra coordination.

[NicolasT]

That's indeed the idea! It could allow for scenarios not possible with Erlang, but that's fine: with STM, GHC does provide a way for concurrency control which doesn't exist in other platforms, so why not leverage it?