Re: [boost] [block_ptr] Request for a review manager

Subject: Re: [boost] [block_ptr] Request for a review manager
From: Phil Bouchard (philippeb8_at_[hidden])
Date: 2016-02-09 01:41:31

On 02/08/2016 10:52 PM, Gavin Lambert wrote:
> 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.
>
> Consider
> http://www.boost.org/doc/libs/1_60_0/doc/html/boost_asio/example/cpp11/http/server/connection.cpp.
>
>
> 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.

I had to remove the rust behind my C++ skills to answer that question.

Anything that is not allocated from a pool is "on the stack" so I don't 
see why the generation of lamdba should be any different because this is 
just another function pointer.