Re: netcdf c++ class

> Organization: Texas A&M University
> Keywords: 199502011648.AA08320

Dan,

> > >     for (int i = 0; i < num_dims(); i++) {
> > >       dimensions[i] = new NcDim(this, i);
> > >     }
> > >     for (i = 0; i < num_vars(); i++) {
> > >       variables[i] = new NcVar(this, i);
> > >     }
> > > 
> > > is a memory leak (or are memory leaks).  The
> > > easy fix of "delete dimensions[i];" before
> > > the new hoses anyone who got an NcDim* from
> > > you before (similary for the NcVars).  I think
> > > the easy way out is an NcDim::sync() and an
> > > NcVar::Sync() <thinking as I write>.  I'll give
> > > these a shot, if you see something else
> > > give me a holler.

> I have implemented syncs for var's and dims. Here is the patch (I tested
> heavily for memory leaks.)  It breaks if someone else deletes a var
> or dim that has been seen, but it finds things as they are added.
> I use this to avoid race conditions (e.g. 2 process
> are going to talk through the netcdf file, one of them writes
> it, the other waits for the file to exist and opens the file
> and waits for the the record dimension to get to a certian place
> and then reads the file. I'd like to avoid file close/reopen
> if I could.)

I didn't realize anyone was actually using netCDF this way, needing the
capability to detect if another process adds new dimensions and variables to
an open netCDF file.  I thought it was enough to be able to detect if new
records had been added (which I think works with the simpler NcFile::sync()
in the latest patch).  It may be desirable to ultimately separate the three
ways sync() is being used, to flush writes, to access new data written by
another process, and to incorporate a schema change by another process.
That way users who frequently call sync() just to flush writes wouldn't have
to pay for the overhead required to support the other functions of sync().

In any case, thanks for sending your new code that supports the third use of
sync().  I've forwarded it to another user (Tom LeFebvre
<address@hidden>) who had also noticed the NcFile::sync() memory
leak.  I'll look into incorporating it soon.

______________________________________________________________________________

Russ Rew                                                UCAR Unidata Program
address@hidden                                          P.O. Box 3000
http://www.unidata.ucar.edu/                          Boulder, CO 80307-3000
______________________________________________________________________________