This is the mail archive of the gsl-discuss@sources.redhat.com mailing list for the GSL project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

blocks/views and wrappers


Brian Gough wrote:
>
> I think we can accomodate this in GSL by not setting the block field
> to NULL for views, and having a separate field in the struct to
> indicate ownership of the memory instead.  Then one would always be
> able to determine the underlying block for any view.

Yes, every view should have an associated block. The model should
be completely uniform in that regard. All we need to do is make
sure that we maintain ownership information in the right way.
You should be able to obtain the block and be able to get
information about how the current object fits in the
block, i.e. an offset.

It may be worth pointing out that "block address + offset"
semantics are already present in some parts of GSL, for instance with
gsl_vector_alloc_from_block(). This underlying semantic needs to be made

more uniform across the vector/matrix implementations. Then it would be
easier to work with underlying blocks when necessary.

It is important not to confuse this with reference counting,
or any other memory management scheme. For instance, if a parent
view is reclaimed, then sub views will dangle. I just say that to
avoid any confusion over the use of the word ownership. In our
model, sub views will never inherit ownership of block data
from a parent view.

From the discussion of vsipl blockbind, I assume that even though
it insists on exclusive access, it won't try to do anything like
free the data, under any circumstances. But there is also the
alternate worry, that a GSL app might try to free the block
after it has been bound to an external environment like vsipl.
It may seem that this is an application issue, ie the app programmer
simply must take care not to do this, but maybe there are circumstances
under which he would have no choice. For instance, suppose I
wrote a C++ application where a destructor gets called automatically
(in an inconvenient spot, like after exit from main),
freeing some block data. If vsipl is not yet finished with it
(for instance in a multi-threaded app), there could be mysterious
problems.

This raises the issue of whether or not GSL should be able to
release actual memory management responsibility in some cases.
If no GSL entity claims ownership of a block, then
no GSL entity will release it. It is not that we are necessarily
transferring ownership to an external entity, but simply that
we are unilaterally dis-owning the object. So I think there
should be something like

  typedef enum { GSL_BLOCK_OWN, GSL_BLOCK_DISOWN }
gsl_block_ownership_t;
  void gsl_block_ownership_set(gsl_block *, gsl_block_ownership_t);

Then maybe the standard incantation for binding to an external
entity should be something like:

   gsl_block * b;
   ...
   gsl_block_ownership(v, GSL_BLOCK_DISOWN);
   vsipl_blockbind(..., b, ...);
   ...
   vispl_blockunbind(vsipl_block *, ...);
   gsl_block_ownership(v, GSL_BLOCK_OWN);

It may be tedious to keep track of this sort of thing in general.
But my guess is that it would not be so bad in practice, and
obviously it only occurs in specialized circumstances. This
is completely trivial from the GSL implementation point
of view, so why not do it. Can anbody point to a a concrete
exmaple where this would be required (beyond my semi-fake
example of automatic destruction in multi-threaded apps)?


> lower level functions too. So far we have not done that because it was

> not essential -- it could be done but it is easy enough to get by
> using the C arguments, by typing v->data, v->stride, v->size instead.
> A gsl_vector version of low-level functions would mainly be a
> convenience.

Well, it's more than just a convenience. Just as it is important
to insulate the user from implementation details, it is also
important to insulate the different parts of the library from
their respective implementation details. As Brian knows, I am
very insistent on this point. Anyway, everybody
in this forum understands this.

Those struct elements should be hidden, and managed in
as well-contained an area as possible.

There should be wrappers, and the reason they are not done
is not because they were deemed inessential by anyone, but
simply because they are not done. Somebody needs to type
them in. At some point before 1.0, somebody will.


--
G. Jungman



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]