On Mar 8, 2013, at 11:55 , Jeff Squyres (jsquyres) <jsquyres_at_[hidden]> wrote:
> On Mar 7, 2013, at 7:37 PM, George Bosilca <bosilca_at_[hidden]> wrote:
>> An example will be a memory region without a predefined size, that I manipulate as opal_list_item_t. This fragment gets allocated when it's size is know, then gets OBJ_CONSTRUCT'ed and then used. The reference count is playing its role, when nobody is using the object anymore, it will be automatically released. With the change you propose such usage will be prohibited.
> Ah, ok -- are you saying to do the following:
> myobj = malloc(...);
> OBJ_CONSTRUCT(myobj, ...);
> If so, yes, I agree, #1 would disallow that [valid] use case. And we wouldn't want to disallow that.
Yes, this is what I do. As I explained in my previous email, I do't have other choice, as I don't know the size of the object before-hand (preventing the usage of OBJ_NEW). I thought about a new version of OBJ_NEW with an argument (which will be the size of memory to allocate), but I discarded it as an overkill.
> But that's ok; #2 is the important one -- #1 just seemed like a good compliment to what was already there that we figured we'd do at the same time. But we didn't know if there were other valid use cases that #1 would violate, which is why we RFC'ed/asked.
>> PS: The second patch (ref count == 1 in OBJ_DESTRUCT) is trivial but reasonable.
> Yeah -- unfortunately, while the patch to add that assert() is trivial, it's finding lots of ref counting bugs in the MPI layer, so I don't want to commit it yet. :-) I'll come back with more info after I've sorted through them
Correctly used, OBJ_NEW / OBJ_CONSTRUCT / OBJ_DESTRUCT, are not a bad set of macros. When an object is not needed and known not to be refereed anymore, it can safely be OBJ_DESTRUCT despite the fact that its reference count is not 1. Otherwise, in all BTLs we will have to put all fragments back in the right place, remove them from all lists, before calling the destructor. In other words, no collection class in Open MPI will work correctly, especially not the one we use the most often the ompi_free_list.
> Jeff Squyres
> For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/
> devel mailing list