On 9/02/2014 02:14, Quoth Bjorn Reese:
As we are exploring the limitations of the Asio model, I would say that the mode can change in any imaginable manner: it could alternate between two modes on each request, or it could change only a subset of the requests rather than all, just to name two. And this would be completely transparent to the client, because it the general case it is not simply a matter of accepting or rejecting requests, but about processing them differently.
I still think you're imagining a scenario that doesn't make sense in practice.
So I guess that it boils down to:
1. Can I replace a continuation after the function has been initiated?
You have to have something that is holding the continuation so that it can be called later. There's no reason *in principle* why this cannot be handed from one object to another as desired as long as the conceptual operation is still in progress as far as the caller is concerned. (In fact, this actually happens in ASIO -- a pending operation is held by the I/O object until it completes, then is passed to the generic scheduler to execute the user handler.) If something significant happens that the caller is likely to want to know about (such as changing license state etc), then it may be worthwhile cancelling the connection (by calling back with an error code) and getting the client to reconnect, because it might want to set up a different set of pending operations / subscriptions given the new state. When there are multiple pending operations, there's no reason why you can't cancel some, initiate others, and leave the rest going (depending on what makes sense for the particular change in question). (I said "in principle" above because the current ASIO model makes heavy use of templates for performance and to enable auxiliary features such as strands and custom allocation; the way that it's implemented at the moment these can't survive a type-erasure boundary such as would be required to pass through an RPC system. Instead you'd have to replicate these on each side -- but you'd probably want that anyway.)
2. Can I group several of such replacements so that they will be replaced at the same time (or at least before the next event occurs)?
In the context of "a thing that implements ASIO-like callbacks", sure. As I said above, you'd just have to move the list of pending operations from one implementation to the other, and the caller wouldn't know the difference as long as whatever handle it uses to make async requests is still valid. (Things get hairier if you're processing events on multiple threads, though.) In the context of ASIO specifically, not really, at least not once the operations have been marked as complete and ready to execute. But I'm still not really sure why you'd want to.