Effectively immutable message context

[mhelleborg]

IContext in IActor today uses the mutable ActorContext directly. This works fine when processing strictly in the context of the actor itelf, but after processing a message the context is updated.

By making the context immutable, some new abstractions become available, like storing the context and responding / forwarding later,, or batch processing and responding to messages.

cc @rogeralsing Any thoughts on this?

[rogeralsing]

This was one of the original ideas behind passing in context in the receive method.
As Go was the first implementation and Go has structs, this felt like a natural fit.

But it does end up causing one new allocation per message (no matter how it is done, something new per message will have to hold this state), which can be extremely heavy if you want raw compute power.

Another option could be to have some form of context.Freeze() method returning a FrozenContext instance, which does this for you, but in an explicit way.

This is all also complicated by the fact that if an actor restarts, it still have the same context, but the Actor instance is recreated. what should the frozen context point to, the actor instance that existed when it was created?
meaning an object that is no longer in use.

Or, if it were to point to the currently active Actor instance at all times, the frozen context would be semi-mutable.

A lot of edge cases that needs to be sorted out before going down such route

[mhelleborg]

I guess a .Freeze() abstraction would give some good tradeoffs, where we do not pay for the allocation unless needed.

When it comes to the actor reference, that needs to be solved as well ofcourse. Will need to have a look at how ActorContext is used across restarts. But there is nothing wrong with having a mutable pointer in our "Frozen" context, as long as it has "immutable" semantics for sender, message and headers.