Why should I use sender closure with PipeTo ()?

Here is the official sample using PipeTo() in Akka.NET:

 Receive<BeginProcessFeed>(feed => { //instance variable for closure var senderClosure = Sender; SendMessage(string.Format("Downloading {0} for RSS/ATOM processing...", feed.FeedUri)); //reply back to the sender _feedFactory.CreateFeedAsync(feed.FeedUri).PipeTo(senderClosure); }); 

The question is why should we use Sender here? Why not just use:

 _feedFactory.CreateFeedAsync(feed.FeedUri).PipeTo(Sender); 

In this example and in the documents it is said that it is mandatory to use closure here. But I see no reason for this.

If we used ContinueWith() , it PipeTo() sense to use a closure inside the continuation, but not as the PipeTo() parameter.

Did I miss something?

+5
source share
1 answer

Two things to understand here:

  • Sender not a static property. Sender is actually a function on the IActorContext that returns the sender of the currently processed message. The return value changes each time the context receives a new message from the mailbox.

  • PipeTo is a continuation, and when this continuation is executed in threadpool, the Sender call will gain access to the same IActorContext tag that launched the task. There is no guarantee that the current Sender in the context is the same, due to the fact that a new message has been pushed to the actor for processing from the moment the task starts.

So, we cache the Sender value in the local variable to ensure that we aim PipeTo on the correct IActorRef whenever it is executed.

+5
source

All Articles