Messenger Lib: Synchronous call for interruptable action?

[ConnerP]

So I have a motion control actor where I would like to be able to send a STOP command while motion is running. I would also like for a specific caller to wait until the motion is complete. Doing a standard Query does not work, because the reply happens at the end of the action stack and does not leave the actor available to get STOP messages. I considered several options.

1) Pass in a future with the move message, store it while checking for motion complete in the timeout, fulfill it when the motion is complete.
2) Somehow subscribe for a motion complete notification, but I would only want to wait on the motion that is called right there, or at least the first motion after the call. I didn't think of a good way to synchronize this. However, now when typing I guess a call for a motion could receive an identifier which could be the data to a "motion complete" notification and then the caller could check for that.
3) strip the reply address from the move message so it doesn't get replied to right at the end of the action stack, cache it, and reply once motion is complete.

I went for option 3 but would like to hear others thoughts, particularly James. 

Regarding option 2, I was wondering if it would make sense to offer an API for bundling a registration message (for a one-off query of the notification) with a standard message. That way you know the registration happens immediately before that actual message with nothing in between. Maybe this is already possible, but I couldn't figure it out.

[drjdpowell]

I would probably do what you have done. 

Ideally, it would be great to have the ability to send two messages atomically, meaning no chance of any other message or action getting in-between, but unfortunately the underlying Queue or User Event can't do that.  It's hard the think of an API that does this cleanly, without a similar amount of work to what you have done 

BTW, just to give another option, if the only to thing needed is the ability to abort, one can use an "Abort Token".  Your motor actor would execute the move as one action, but would receive a Queue that it can periodically check is still valid.  This is provided by the caller in the move request, and can be destroyed to signal abort.  This has advantages and disadvantages and would probably not be best for a motor move.

[ConnerP]

Thanks for the feedback. That is a good idea with the abort token. I will keep it in my back pocket for the future.