On 02/05/2016 07:34 AM, Paul A. Bristow wrote:

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Phil Bouchard Sent: 05 February 2016 04:29 To: boost@lists.boost.org Subject: Re: [boost] [block_ptr] Request for a review manager

On 02/03/2016 09:02 PM, Phil Bouchard wrote:

...

Greetings,

As some of you might know I work full time on WebKit which in turn uses a garbage collector for its Javascript interface and quite honestly a garbage collector is not ready for a commercial release unless you have a lot of CPU juice. So a garbage collector is unacceptable.

On the other hand I code completed the deterministic block_ptr in 2011 and I am wondering if there is anything I am missing to get it through the review process because this is one of the most important subject in computer science: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/doc/i ndex.html

Please let me know if you are interested for me to present it and answer questions live.

I know little of this subject (apart from a belief that garbage collection should not be necessary for C++ ;-) but having glanced at your documentation, I'm sure it has some uses.

But to become a Boost library it needs to have the right structure of files in Github https://svn.boost.org/trac/boost/wiki/StartModDev so that it can be viewed and tried out by potentially interested persons. http://www.boost.org/development/submissions.html is helpful.

Tests are essential and in the right format to run with the Boost.Build bjam/b2 toolchain so that your library can be tested on various platforms. You also have some examples available and users also need to be able to run these using bjam/b2.

The documentation appears to have the right content but looks a little clunky and could easily be rejigged into the Quickbook style. Since you already have Doxygen syntax comments, these could be added along with an automatically generated index. http://www.boost.org/doc/libs/1_60_0/doc/html/circular_buffer.html is a typical example of a small library. I can assist with refactoring if you get further down the review process.

Finally you need to find a review manager and preferably some real-life users who can review knowledgably.

Thanks for the clarifications. There are real-life users in the WebKit world but this world isn't interested into cutting-edge C++. I'll see what I can do. Regards, -Phil

On 8/02/2016 08:35, Phil Bouchard wrote:

...

But to become a Boost library it needs to have the right structure of files in Github https://svn.boost.org/trac/boost/wiki/StartModDev so that it can be viewed and tried out by potentially interested persons. http://www.boost.org/development/submissions.html is helpful.

I added the new repository with the right folder structure: https://github.com/philippeb8/block_ptr

One thing you perhaps might want to consider is whether you intend this to be a library in its own right or as an addition to the existing smart_ptr library -- each case requires different structures and discussing things with different people.

I can tell everyone right now: a garbage collector has no place in the commercial industry as most of you might know. If there is no memory leak then there's going to be high CPU usage running in the background and the side effect will be a lagging user interface.

Given that I prefer writing UI in C#, we might have a difference of opinion there. :) What is obvious truth in one domain may not be so in another. 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?

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/.... 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.

Gavin Lambert wrote:

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/....

Reading rationale.html, it says "If it is found to be living on the heap then a more complicated mechanism is involved to track the last memory block that was allocated in the same thread, find its address and stack up the set it will be part of until the first block_ptr<T> found on the stack is or data segment is initialized, where the new set counter will be shared with all of the newly allocated blocks of memory referencing each other." so it looks like other, simpler examples, could also pose problems. Something like vector v; v.reserve( 5 ); // do something that allocates from the heap v.emplace_back( new X ); The last line constructs a block_ptr<X> inside the vector's allocated memory, which is on the heap. So the block_ptr goes looking for a previous heap allocation and finds some random one.

On Tue, Feb 9, 2016 at 5:02 PM, Peter Dimov wrote:

...

// do something that allocates from the heap

v.emplace_back( new X );

The last line constructs a block_ptr<X> inside the vector's allocated memory, which is on the heap. So the block_ptr goes looking for a previous heap allocation and finds some random one.

Ah wait, the last allocation is "new X" here. Hmm.

You can't tell that without seeing X's constructor. It may well be another allocation that is performed in X().

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Phil Bouchard Sent: 07 February 2016 19:35 To: boost@lists.boost.org Subject: Re: [boost] [block_ptr] Request for a review manager

On 02/05/2016 07:34 AM, Paul A. Bristow wrote:

...

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Phil Bouchard Sent: 05 February 2016 04:29 To: boost@lists.boost.org Subject: Re: [boost] [block_ptr] Request for a review manager

On 02/03/2016 09:02 PM, Phil Bouchard wrote:

...

Greetings,

As some of you might know I work full time on WebKit which in turn uses a garbage collector for its Javascript interface and quite honestly a garbage collector is not ready for a commercial release unless you have a lot of CPU juice. So a garbage collector is unacceptable.

On the other hand I code completed the deterministic block_ptr in 2011 and I am wondering if there is anything I am missing to get it through the review process because this is one of the most important subject in computer science: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/doc/i ndex.html

Please let me know if you are interested for me to present it and answer questions live.

I know little of this subject (apart from a belief that garbage collection should not be necessary for C++ ;-) but having glanced at your documentation, I'm sure it has some uses.

But to become a Boost library it needs to have the right structure of files in Github https://svn.boost.org/trac/boost/wiki/StartModDev so that it can be viewed and tried out by potentially interested persons. http://www.boost.org/development/submissions.html is helpful.

I added the new repository with the right folder structure: https://github.com/philippeb8/block_ptr

...

Tests are essential and in the right format to run with the Boost.Build bjam/b2 toolchain so that your library can be tested on various platforms. You also have some examples available and users also need to be able to run these using bjam/b2.

The tests and the examples are all there as well.

OK - look promising.

...

Finally you need to find a review manager and preferably some real-life users who can review knowledgably.

I cannot imagine there is no real-life user here because WebKit is the ultimate link between C++ and Javascript and a memory manager is the bottom line here. Even QML would need a memory management makeover.

I meant Boost/readers/users who can contribute to a review.

I can tell everyone right now: a garbage collector has no place in the commercial industry as most of you might know. If there is no memory leak then there's going to be high CPU usage running in the background and the side effect will be a lagging user interface.

And perhaps more important, a sagging battery? Is battery life not the more important reason to avoid garbage collection for portables? Paul --- Paul A. Bristow Prizet Farmhouse Kendal UK LA8 8AB +44 (0) 1539 561830

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of charleyb123 . Sent: 09 February 2016 14:54 To: boost@lists.boost.org Subject: Re: [boost] [block_ptr] Request for a review manager

...

...

I can tell everyone right now: a garbage collector has no place in the commercial industry as most of you might know. If there is no memory leak then there's going to be high CPU usage running in the background and the side effect will be a lagging user interface.

And perhaps more important, a sagging battery?

Is battery life not the more important reason to avoid garbage collection for portables?

And, electricity costs "at-scale". ;-)

And, most especially data center cooling costs. ;-)

And, the opportunity costs of lower processing throughput for increasingly large data sets. ;-)

And, the less scalability for concurrent and parallel systems. ;-)

And, the shortened component lifespan due to increased loads. ;-)

And, the poor engineering design incentives they encourage. ;-)

And, the confusion/sloppiness and non-determinism present in the resulting systems. ;-)

And, ... ;-)

I think that you are preaching to the converted? ;-) Paul

On 02/09/2016 09:45 AM, Paul A. Bristow wrote:

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Phil Bouchard Sent: 07 February 2016 19:35 To: boost@lists.boost.org Subject: Re: [boost] [block_ptr] Request for a review manager

On 02/05/2016 07:34 AM, Paul A. Bristow wrote:

...

...

-----Original Message----- From: Boost [mailto:boost-bounces@lists.boost.org] On Behalf Of Phil Bouchard Sent: 05 February 2016 04:29 To: boost@lists.boost.org Subject: Re: [boost] [block_ptr] Request for a review manager

On 02/03/2016 09:02 PM, Phil Bouchard wrote:

...

Greetings,

As some of you might know I work full time on WebKit which in turn uses a garbage collector for its Javascript interface and quite honestly a garbage collector is not ready for a commercial release unless you have a lot of CPU juice. So a garbage collector is unacceptable.

On the other hand I code completed the deterministic block_ptr in 2011 and I am wondering if there is anything I am missing to get it through the review process because this is one of the most important subject in computer science: https://svn.boost.org/svn/boost/sandbox/block_ptr/libs/smart_ptr/doc/i ndex.html

Please let me know if you are interested for me to present it and answer questions live.

I know little of this subject (apart from a belief that garbage collection should not be necessary for C++ ;-) but having glanced at your documentation, I'm sure it has some uses.

But to become a Boost library it needs to have the right structure of files in Github https://svn.boost.org/trac/boost/wiki/StartModDev so that it can be viewed and tried out by potentially interested persons. http://www.boost.org/development/submissions.html is helpful.

I added the new repository with the right folder structure: https://github.com/philippeb8/block_ptr

...

Tests are essential and in the right format to run with the Boost.Build bjam/b2 toolchain so that your library can be tested on various platforms. You also have some examples available and users also need to be able to run these using bjam/b2.

The tests and the examples are all there as well.

OK - look promising.

...

...

Finally you need to find a review manager and preferably some real-life users who can review knowledgably.

I cannot imagine there is no real-life user here because WebKit is the ultimate link between C++ and Javascript and a memory manager is the bottom line here. Even QML would need a memory management makeover.

I meant Boost/readers/users who can contribute to a review.

...

I can tell everyone right now: a garbage collector has no place in the commercial industry as most of you might know. If there is no memory leak then there's going to be high CPU usage running in the background and the side effect will be a lagging user interface.

And perhaps more important, a sagging battery?

Is battery life not the more important reason to avoid garbage collection for portables?

Lol... I agree