Open MPI logo

Hardware Locality Development Mailing List Archives

  |   Home   |   Support   |   FAQ   |   all Hardware Locality Development mailing list

Subject: Re: [hwloc-devel] release status
From: Jeff Squyres (jsquyres_at_[hidden])
Date: 2009-10-05 10:02:12


On Oct 5, 2009, at 9:23 AM, Fawzi Mohamed wrote:

> yes you are right, I was unclear, I meant that I would pass a cpu_set
> struct by value (not always pass a pointer).
> If one wants to later migrate to passing just a pointer, then
> internally this struct can have just a single pointer as field.
>

Ah, gotcha.

But if that struct contains a dynamically-malloced pointer, then we
might get issues about confusion of ownership of the sub-data...

> indeed, if you alloc, and it is fixed size (no sparse structure) then
> one can just call free, but in general having a structure specific
> free function gives just a lot more flexibility for the future (and is
> needed to copy unknown size structs).
>

I agree about the future, but it would seem weird if we have alloc/
free functions for public structs. No one will use them, and then
when/if we *do* change to opaque handles (or equiv), they *will* have
to change their code. Kinda defeats the point.

So I think we can't go half-n-half -- it's either public structs until
2.0 or something opaque (where you *have* to use hwloc alloc/free
functions).

-- 
Jeff Squyres
jsquyres_at_[hidden]