On 23/01/2014 06:37, Quoth Bjorn Reese:
The first limitation pertains to chained operations. In Asio you chain operations by initiating the next operation when you receive a callback from the previous operation. Although we can initiate several operations at the same time, these operations are not chained. I am going to ignore scatter I/O here because they have their own limitations (e.g. they either multiple reads or multiple writes, but not combinations thereof.)
I'm having trouble understanding this. A chained operation must by definition be one operation being called as some other operation completes, and can never possibly refer to operations running in parallel. You can certainly have multiple operations related in fashions other than chains, either by giving them the same callback target object, or by calling them through the same strand, or by calling them on some object that has some internal policy about how concurrent operations are managed, or by making a new composite operation that internally manages sub-operations in a fashion invisible to the caller.
The second limitation is about multiple types. The Asio model assume that there is a one-to-one correspondence between the type that I request and the type I receive. This is perfectly fine for Asio because it just deals with buffers. However, if you create an asynchronous RPC server using the same kind of callback mechanism as Asio, then you want request a function of any type and receive a function of a specific type. In this design you have multiple "return types" (received function signatures.)
Or each "function" is just a custom async operation. You don't request a function and then try to interrogate it, you just execute operations. It's pretty easy to define new I/O objects in the ASIO model and give them whatever async functionality you want. Granted, it's all in-process, so you'd have the added complication of injecting some sort of serialisation and remoting to make it RPC, but it's still fairly readily achievable, I think.