Hi guys, Sam and I raised this question for the following reason (motivated during the discussion of BMI-MX's design with Scott) Suppose a BMI method wants to keep around a pre-allocated pool of unexpected buffers, it seems wasteful to copy them into a user buffer and then free it again. So we were kind of wondering if a test_unexpected() returns one of those preallocated buffers (and mark them internally as being used) and then the caller can then call BMI_memfree() which will return it to the pool of unexpected buffers (by marking them as free again).
But if this does not appeal to you guys, I suspect the unexpected_free() callback function would also be better than free().. Thanks, Murali > > For my 2c, I would prefer one of these approaches: > > - the current mechanism (make user call free()) > > - add a BMI function specifically for freeing unexpected buffers > (BMI_unexpected_free() or something like that). > > The latter approach would just be implemented by calling free() for the > current methods, and future methods would have the freedom to do > whatever they please. I would rather not overload the BMI_memfree() > function since it is meant to be paired with BMI_memalloc() and would > imply that we are dictating that the unexpected buffer be optimized for > communication. I also would also rather not add any extra arguments or > function calls to specify the unexpected buffer in advance- as Pete > points out that can get icky in a hurry. > > As far as the lifetime rule for the unexpected buffer... the only reason > we held onto it that long was to support the possibility of having > encoding mechanisms that decode "in place". If someone were to > implement that, then of course the unexpected buffer would need to hang > around until after PINT_decode_release() is called. Personally, I'm not > particularly interested in that type of en/decoding because it is hard > to make something like that work in heterogeneous environments. My vote > is to go ahead and destroy the unexpected buffer sooner if possible. If > anyone ever wants to go through the pain of implementing an in-place > decoder then they can move the free back to a later point again (it > isn't a difficult change). > > -Phil > _______________________________________________ > Pvfs2-developers mailing list > Pvfs2-developers@beowulf-underground.org > http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers > > _______________________________________________ Pvfs2-developers mailing list Pvfs2-developers@beowulf-underground.org http://www.beowulf-underground.org/mailman/listinfo/pvfs2-developers
