Are messages to self, delivered *before* other messages ?

[nsengupta]

I am trying to see how an Actor can be ergonomically intertwined with a State Machine.

I have reasonably good exposure of building such components using Scala/Akka (a few PROD level implementations). The FSM trait and the idiom of State Transition (using partial functions) in Akka, make it very intuitive to model such behaviour and as a bonus, the code is very readable.

However, here, I am using two different libraries - one is Ractor - and one guarantee seems to be missing is this: if for forcing a transition, I want to send an event to myself so that, the State Machine moves to a target state, I have to ensure that this self-directed message is processed, before the next message (from another actor) is processed.

Example:
Current Q: << M3, M2, M1 >> // messages are pushed, the last that came in, is the leftmost.
FSM (internal to the Actor) is at State [A]

• Actor processes M1
• FSM moves to a State [DecisionMaker]
• This is an intermediate State. At this State, the logic entails a decision; based on the decision, the FSM should settle for next (stable) State; say State [B] or State [C].
• Actor runs the decision-making logic
• Importantly, the FSM must be in either State [B] or State [C] before message M2 (from the Q) is processed.
• A coherent approach for the Actor will be to send to itself, a message like DoThisAndMoveToStateB or DoThisAndMoveToStateC. That way the Actor's implementation remains clean and coherent: it doesn't stir into action, w/o a message that comes to it.

But for this to happen deterministically, after the decision-making logic is finished, the Q should look like this:

Current Q: << M3, M2, DoThisAndMoveToStateB >> // messages are pushed, the last that came in, is the leftmost.

The world will remain a happy place! :-)

The Q I have is: will ractor ensure this or I have to deal with the situation, by using my own code-structure?

[slawlor]

So if you want to send an actual message to the actor it'll go through the same shared message queue that all messages use. Meaning that first come, first served which is true to Erlang OTP. This means that if there's already messages in the queue (from anyone), any new incoming messages will end up at the back of the queue, including from self. There's no priority queueing or anything like that.

That being said, what you described can be modelled by an actor in an actor. The inner actor's message queue is gated by the parent actor which could interleave messages to change the inner's state. So you could essentially control the inner actor's message queue, threading internal messages along with public ones in the order that you see fit. This also could be abstracted generically relatively easily, such that this would be a pattern you could reuse over and over

Another option is to simply extract the message handling to a method, and call it with your own "higher priority self message", if you need it to take effect over other messages.