On 8/27/2013 11:58 AM, Klaim - Joël Lamotte wrote:

On Tue, Aug 27, 2013 at 5:34 PM, Phil Bouchard wrote:

...

- block_ptr hasn't been reviewed yet but memory management is an important subject. Are there unanswered questions about it?

My current understanding is that it is not clear at all to most of us (me included) what block_ptr is.

Well it's a memory manager but I am not sure where I fail to document its design. -Phil

On Tue, Aug 27, 2013 at 6:08 PM, Phil Bouchard wrote:

Well it's a memory manager but I am not sure where I fail to document its design.

"Memory manager" is very vague.

On 8/27/2013 1:07 PM, Phil Bouchard wrote:

On 8/27/2013 12:22 PM, Klaim - Joël Lamotte wrote:

...

"Memory manager" is very vague.

Well it's a deterministic memory manager because the time of the destruction of the objects is predictable.

If it was ported to Java there would be no need for the "finally" clause anymore.

I am not sure what else to tell you. -Phil

On 8/30/2013 4:43 PM, Jens Weller wrote:

I'll just ask about the elephant in the room: What does your block_ptr do differently then the for years known smartpointer implementation in boost? Why is there a need for reinventing the wheel?

Because cyclic pointers need to be handled explicitly with smart pointers whereas with mine it's done implicitly. That's why it can be ported to Java so easily. I have my take on smart pointers because I am working on Webkit which uses its own similar smart pointers to Boost's. I haven't been promoting block_ptr much in the last 2 years simply because I was working on my astrophysics project. -Phil

There's no one correct destruction order for objects participating in a cycle. That's one reason most C++ garbage collectors collect memory but don't run destructors. How does your system deal with this?

I can think of another reason: The whole point of garbage collection is to simulate unbounded memory by recycling memory that is no longer reachable. If you run destructors on objects that are collect as garbage, the simulation is no longer a simulation.

2013/8/31 Dave Abrahams

on Fri Aug 30 2013, Phil Bouchard wrote:

...

On 8/30/2013 4:43 PM, Jens Weller wrote:

...

I'll just ask about the elephant in the room: What does your block_ptr do differently then the for years known

smartpointer implementation in boost?

...

Why is there a need for reinventing the wheel?

Because cyclic pointers need to be handled explicitly with smart pointers whereas with mine it's done implicitly.

There's no one correct destruction order for objects participating in a cycle. That's one reason most C++ garbage collectors collect memory but don't run destructors. How does your system deal with this?

It still can be usable for types with trivial destructor. (However it is hard to imagine any smart ptr with trivial destructor, so making a cycle of trivial types with smart pointers seems impossible.). Can we see the implementation of block pointer? -- Best regards, Antony Polukhin

2013/8/31 Vicente J. Botet Escriba

Le 31/08/13 07:48, Antony Polukhin a écrit :

It still can be usable for types with trivial destructor. (However it is

...

hard to imagine any smart ptr with trivial destructor, so making a cycle of trivial types with smart pointers seems impossible.). Can we see the implementation of block pointer?

Hi, block_ptr in on the review schedule since a long time. See https://svn.boost.org/svn/boost/sandbox/block_ptr/

Looks promising and inteesting. But not 100% ready. For example this singleton is not thread safe in C++98/C++03: static mutex & static_mutex() /**< Main global mutex used for thread safety */ { static mutex mutex_; return mutex_; } Also use BOOST_NOEXCEPT_OR_NOTHROW instead of throw(), BOOST_NOEXCEPT instead of /* newer throws*/. Mark noexcept destructors, copy, move constructors, assignment operators with BOOST_NOEXCEPT where appropriate, Please add notes about the issue mentioned by Dave (correct destruction order for objects participating in a cycle) If nobody minds, I can become the release manager for this library. However I'll have enough time for this only at the beginning of this winter. -- Best regards, Antony Polukhin

On 8/31/2013 11:24 AM, Phil Bouchard wrote:

Thanks. But I must also say the object allocator could be speed up because at the time I wrote this there was no way to allocate consecutive bytes from a pool in constant complexity. I am still using fast_pool_allocator: https://svn.boost.org/svn/boost/sandbox/block_ptr/boost/block_ptr.hpp

That's one more improvement that can be done and it'll be perfect.

Sorry I didn't mean this allocator but boost::singleton_pool: https://svn.boost.org/svn/boost/sandbox/block_ptr/boost/detail/block_base.hp... -Phil

On Tue, Sep 3, 2013 at 10:39 PM, Phil Bouchard wrote:

May I ask what is the level of understanding of block_ptr in percentage?

I don't know how "percentage" could be applied here but the following is how I understand it: 1. from the interface and behaviour expectations point of view, it's exactly like shared_ptr. (is there a weak_ptr too?) 2. however the implementation is made so that cycles are not a problem, they are destroyed in a deterministic way; All the rest is confuse to me so far, but then I have a quesiton: Can block_ptr be considered as a specific implementation of shared_ptr which allows cycles? If yes, what are the costs for the user, compared to shared_ptr? Joel Lamotte

On 9/3/2013 5:33 PM, Phil Bouchard wrote:

block_ptr is a cycle manager on top of a shared_ptr but the sizeof(block_ptr) remains == to sizeof(shared_ptr).

Sorry: block_ptr is a cycle manager on top of reference counting but the sizeof(block_ptr) remains == to sizeof(shared_ptr). -Phil

On 8/31/2013 1:06 PM, Phil Bouchard wrote:

On 8/31/2013 11:24 AM, Phil Bouchard wrote:

...

Thanks. But I must also say the object allocator could be speed up because at the time I wrote this there was no way to allocate consecutive bytes from a pool in constant complexity. I am still using fast_pool_allocator: https://svn.boost.org/svn/boost/sandbox/block_ptr/boost/block_ptr.hpp

That's one more improvement that can be done and it'll be perfect.

Sorry I didn't mean this allocator but boost::singleton_pool: https://svn.boost.org/svn/boost/sandbox/block_ptr/boost/detail/block_base.hp...

One more improvement that could also be done would be to make the global mutex static_mutex() "set" oriented: https://svn.boost.org/svn/boost/sandbox/block_ptr/boost/block_ptr.hpp This way modifications to a "set" could be made per thread; i.e. a "set" would be thread independent from each other. But this is not trivial unless we work together on this. -Phil

On 8/31/2013 11:14 AM, Phil Bouchard wrote:

It keeps track of the order of construction and so their are deleted in the order of construction so that their members are deleted first. It also blocks before an attempt to delete a heap object that is already being marked for deletion as you can see in ~block_ptr(): https://svn.boost.org/svn/boost/sandbox/block_ptr/boost/block_ptr.hpp

*It keeps track of the order of construction and so they are deleted...

On 31/08/2013 17:14, Phil Bouchard wrote:

It keeps track of the order of construction and so their are deleted in the order of construction so that their members are deleted first.

Did you mean deleted in the reverse order of construction ? MAT.

On 8/31/2013 1:22 PM, Phil Bouchard wrote:

So you have a cyclic list:

+-> 1 -> 2 -> 3 -+ | | +----------------+

1 will be called for destruction first but the pointer to 2 and then 3 will deleted beforehand because they are their members. The pointer of 3 to 1 will be ineffective.

And if you have: +-> 1 -+ +-> 2 -+ | | | | +------+ +------+ 1 will be deleted then 2. -Phil

On 8/31/2013 2:15 PM, Phil Bouchard wrote:

Note that in order to end up with the aforementioned case we need to start with:

+-> 1 -------> 2 -+ | | +-----------------+

+-> 1 -+ +-> 2 -+ | | | | +------+ +------+

Remember that it works by sets so this example is a set that gets split up. -Phil

...

...

+-> 1 -------> 2 -+ | | +-----------------+

+-> 1 -+ +-> 2 -+ | | | | +------+ +------+

have a container to hold smart pointer to every object , and let them use weak pointer to each other. thus cyclic avoided. cyclic means wrong "owner". if 2 is not owned by 1, how can you use shared pointers?

On 8/31/2013 1:22 PM, Phil Bouchard wrote:

So you have a cyclic list:

+-> 1 -> 2 -> 3 -+ | | +----------------+

1 will be called for destruction first but the pointer to 2 and then 3 will deleted beforehand because they are their members. The pointer of 3 to 1 will be ineffective.

The pointer of 3 to 1 will be ineffective because 1 is marked for deletion. -Phil

On 27 August 2013 17:08, Phil Bouchard wrote:

On 8/27/2013 11:58 AM, Klaim - Joël Lamotte wrote:

...

On Tue, Aug 27, 2013 at 5:34 PM, Phil Bouchard wrote:

...

- block_ptr hasn't been reviewed yet but memory management is an important subject. Are there unanswered questions about it?

My current understanding is that it is not clear at all to most of us (me included) what block_ptr is.

Well it's a memory manager but I am not sure where I fail to document its design.

Why is in the top-level directory? Why does include <iostream>?

On 9/2/2013 10:31 AM, Phil Bouchard wrote:

On 9/2/2013 6:44 AM, Jonathan Wakely wrote:

...

Why is in the top-level directory?

Maybe it belongs to shared_ptr but I am not certain.

I meant: smart_ptr. -Phil