Fork-join in the actor model

Question

I'm reading a paper about the actor model and they describe how a fork-join behaviour can be implemented using it:

Let us consider how a system of actors, when requested to calculate some value, can split up the load among themselves and combine the results to form the final answer. Actor F receives a request message to calculate the value f(x) = h(g1(x),g2(x)) and send the reply to the actor R. Actor F then creates an actor H and sends a message to G1 requesting it to calculate g1(x) and send its reply to H. Simultaneously, F sends a message to G2 requesting it to compute g2(x) and send its reply to H. Assuming that G1 and G2 are both total, H will receive messages from both G1 and G2 containing the values g1(x) and g2 (x), respectively. Now because of the arbiter on H, these two messages are guaranteed to arrive at H in some order, but the order cannot be predicted. Therefore, the reply messages to H will also contain an indicator 1 or 2 to tell H that they were sent by G1, or G2, respectively. The script for H specifies that H is to wait until it has received replies from both G1 and G2, and when it has, it is to compute h(g1(x), g2(x)) and send that value to R;

Now, what I'm not sure about is the passage:

The script for H specifies that H is to wait until it has received replies from both G1 and G2, and when it has, it is to compute h(g1(x), g2(x)) and send that value to R;

Does this imply that the actor H has to be in a sort of "busy wait" to receive these messages? If so, wouldn't the actor be actively running and therefore not able to receive messages?

Am I reading too much into it and they just meant that the actor is activated once both of the messages arrive?

Answer 1

I imagine H not to be spin-waiting. Recall that agents operate on messages they receive. So, it receives the first message to its inbox, but can't do anything with it until the second result arrives. So it (possibly saves the message for later and) goes back to sleep until another message wakes it up. Once it receives the second message, it processes h(message1, message2), and sends the result message to R.

The fact that message1 and message2 are the results of g1(x) and g2(x) respectively are not relevant to Agent H. And as a consequence often there needs to be some identifier (handle) to provide a context for which two messages belong together.