Boost logo

Boost :

Subject: Re: [boost] [block_ptr] Request for a review manager
From: Gavin Lambert (gavinl_at_[hidden])
Date: 2016-02-08 22:52:18

On 9/02/2016 16:14, Phil Bouchard wrote:
>> Getting back on topic, one of the things that bothers me about block_ptr
>> (from looking at the docs only) is that it appears to be incompatible
>> with async methodologies, where memory is constructed and then pushed
>> into a queue somewhere for later action (and sometimes that queue is in
>> application code, sometimes in Boost.Asio or a similar reactor, and
>> sometimes in the OS itself, and often all three at different times).
>> From what I can tell, these would be treated as orphaned pointers and
>> be subject to destruction mid-operation. Or am I missing something?
> I would need some code example to look into this specific use case.

This is probably not the best example of the case, but it's at least one
that's convenient to hand.


While the read/write operations are "in flight", the "self" variable is
a shared_ptr that's stored in some arbitrary location (most likely
heap-based, since the caller stack will be destroyed) that's defined by
a combination of the compiler's lambda generation and Asio's callback
handler management.

Now, this implementation assumes that only one operation (either read or
write, but not both) can be in flight at once, and so it also uses
member fields for the buffers.

Imagine similar code where that doesn't hold, and (ignoring performance
considerations for the moment), imagine that the start of the operation
allocated the buffer locally and then passed ownership of it to the
"operation", to finally be released inside the handler.

I don't see how any of these pointers could be block_ptrs without
breaking things, unless its definition of "being on the stack" includes
being in a deferred lambda.

Perhaps this isn't an intended use, but the docs seem a bit light on
examples of real-world use and where you should use one of these rather
than some other pointer type.

Boost list run by bdawes at, gregod at, cpdaniel at, john at