Re: [asio-users] strand-like priority queues

[Christopher K. <ch...@ko...>]

Rutger ter Borg wrote:
> Dear all,
> 
> Suppose I would like to implement time-prioritized handlers for serialized  
> execution, that have to run through an ordinary io_service. A strand-like 
> interface to priority queues based would be desired, 
> 
> io_service.run();
> ...
> io_service.post( prio.push( 1, ... ) )
> io_service.post( prio.push( 0, ... ) )
> io_service.post( prio.push( 2, ... ) )
> // runs 0 // e.g., from low to high
> // runs 1
> // runs 2
> 
> In terms of interface and functionality, I'm looking for a combination of a 
> strand and a priority queue. I have looked in detail at the prioritized 
> handler example.
> 
> Given that example, insertion into the priority queue is delayed up to the 
> point of invocation. I guess for my example this would be too late -- 
> execution priority should be determined at the point of "wrapping", 
> shouldn't it (otherwise you don't know if you have to wait during 
> invocation)? To use the terminology of the example, somehow the priority 
> ordering should be shared between all wrapped_handlers and queued_handlers. 
> Then, when invoking, run all queued_handlers as long as they have higher 
> priority than any other handler. Something like this?

So just to clarify, do you mean if you have two long running async 
operations:

   sock1.async_read_some(..., prio.push(0, ...));
   sock2.async_read_some(..., prio.push(1, ...));

then you:

- do want the async operations to run in parallel

- don't want the sock2 operation's handler to run until the sock1 
handler has run

Is that right?

> How to build a container (prio queue) for unbound handlers? ... Is this a 
> matter of a whole bunch of deadline timers? Looks like that storage of 
> unbound handlers is a recurring theme for me :-)

If you do mean the above, you don't need to store unbound handlers. The 
async operations themselves already store the unbound handlers. You just 
need to store the bound handlers only after the operation has finished 
just like the prioritised_handlers example. However, in addition to the 
example, you would need to keep track of the highest priority operation 
that is still in progress (i.e. just the priority value, not the 
handler). The function object at the top of the queue simply doesn't get 
popped off until its priority exceeds the highest in-progress value.

Cheers,
Chris