Re: [Boost-users] Object pools?
Il 17/02/2010 17:18, Ryan McConnehey ha scritto:
michele.caini@gmail.com wrote:
Simply, That's not as a pool have to work. You are looking for something that is a pool but working not as a pool does. Then what is the definition of a pool? Do you mean that I'm looking for something that is a pool but doesn't work like a Boost.pool?
Ryan
No, sorry. I mean that pool has responsability for manage offered objects, and so it manages them along their life time. Pool will create objects, pool will release and reclaim objects, and pool will delete objects. That's all. You are looking for something that create objects and forbid about them, until you return that objects to the home. Is correct? Really, it's possible but it is not as a pool works, simply. Your idea breaks also raii pattern and you risk to have memory leaks, because not reclaimed objects maybe be lost during their life time. So, in my opinion, it is not a good idea. I think that is better to create a pool of object during pool construction, so delete them during destruction, eventually resizing pool during use. What about a monostate pattern that globally manages objects as a pool and will be destroyed only when program terminates? That's can be a valid alternative, or not?
Hi Michele,
I Don't share your concerns regarding memory leaks with Ryan's idea.
He says he will use shared_ptrs. If the management class always holds
on to a copy of the pointer and so does whoever "checked out" an
object, the object should be guaranteed to not be destroyed if only
pool or outside holder is destroyed, but should be guaranteed to be
destroyed when both are destroyed.
Best,
Dee
On Thu, Feb 18, 2010 at 12:45 AM, Michele Caini
Il 17/02/2010 17:18, Ryan McConnehey ha scritto:
michele.caini@gmail.com wrote:
Simply, That's not as a pool have to work. You are looking for something that is a pool but working not as a pool does. Then what is the definition of a pool? Do you mean that I'm looking for something that is a pool but doesn't work like a Boost.pool?
Ryan
No, sorry. I mean that pool has responsability for manage offered objects, and so it manages them along their life time. Pool will create objects, pool will release and reclaim objects, and pool will delete objects. That's all.
You are looking for something that create objects and forbid about them, until you return that objects to the home. Is correct? Really, it's possible but it is not as a pool works, simply.
Your idea breaks also raii pattern and you risk to have memory leaks, because not reclaimed objects maybe be lost during their life time. So, in my opinion, it is not a good idea. I think that is better to create a pool of object during pool construction, so delete them during destruction, eventually resizing pool during use.
What about a monostate pattern that globally manages objects as a pool and will be destroyed only when program terminates? That's can be a valid alternative, or not? _______________________________________________ Boost-users mailing list Boost-users@lists.boost.org http://lists.boost.org/mailman/listinfo.cgi/boost-users
Diederick C. Niehorster wrote:
the object should be guaranteed to not be destroyed if only pool or outside holder is destroyed, but should be guaranteed to be destroyed when both are destroyed.
The only way I've currently found to have the object destroyed, if the pool is already gone, is to have a static class registered with the boost::shared_ptr. This gives the static class the ability to destroy the object if the pool has unregistered itself. I don't like this as it creates a bottleneck on deletes. Ryan
Michele Caini wrote:
Pool will create objects, pool will release and reclaim objects, and pool will delete objects.
If the pool manages the life time of the object then the pool can't release the object, correct. The pool will at most loan the object to the user.
You are looking for something that create objects and forbid about them, until you return that objects to the home. Is correct?
Did you mean forget instead of forbid. The kind of pool I'm talking about would only forget about those objects that it released. It still needs to manage the life time of the objects it didn't release.
Really, it's possible but it is not as a pool works, simply.
Are you stating that Boost.Pool doesn't work this way or all pools? Is there a definition for a pool that I'm missing. I thought a pool was a collection of objects and an object could be provided to the user. The implementation and life time of the object were left up to the pool.
Your idea breaks also raii pattern and you risk to have memory leaks, because not reclaimed objects maybe be lost during their life time.
In my requirements, to avoid memory leaks, the objects were passed to the user with a boost::shared_ptr.
What about a monostate pattern that globally manages objects as a pool and will be destroyed only when program terminates? That's can be a valid alternative, or not?
I believe the monostate pattern shares its (static) data. Wouldn't this mean the amount of data can't be increased? If the data can't be increased it not as useful to the user when all the objects have been used but more are still needed. Ryan
participants (3)
-
Diederick C. Niehorster -
Michele Caini -
Ryan McConnehey