Again on H5close

Hdf-forum archives
1

All,

I have a hdf5 reader . I load a hdf5 file . After Loading the hdf5 file
, the file is close using H5Fclose . In the destructor of the Reader I
have a call to H5garbage_collect . Now I want to delete the hdf5 file .
But I am not able to delete the file unless , I have a call to H5close()
in the Reader's destructor . Why is it so ?

Regards

Ram

2

You (allmost certainly) did not close all of the opened and created HDF5 objects.

Besides, having H5close() in a file reader's destructor will close the
library for each file. Should you have more than one file in your app,
such is likely to lead to the crashes described before.

  Werner

···

On Thu, 14 May 2009 04:54:24 -0500, Ramakrishnan Iyer <ramakrishnan.iyer@altair.com> wrote:

All,

I have a hdf5 reader . I load a hdf5 file . After Loading the hdf5 file
, the file is close using H5Fclose . In the destructor of the Reader I
have a call to H5garbage_collect . Now I want to delete the hdf5 file .
But I am not able to delete the file unless , I have a call to H5close()
in the Reader's destructor . Why is it so ?

Regards

Ram

--
___________________________________________________________________________
Dr. Werner Benger <werner@cct.lsu.edu> Visualization Research
Laboratory for Creative Arts and Technology (LCAT)
Center for Computation & Technology at Louisiana State University (CCT/LSU)
239 Johnston Hall, Baton Rouge, Louisiana 70803
Tel.: +1 225 578 4809 Fax.: +1 225 578-5362

----------------------------------------------------------------------
This mailing list is for HDF software users discussion.
To subscribe to this list, send a message to hdf-forum-subscribe@hdfgroup.org.
To unsubscribe, send a message to hdf-forum-unsubscribe@hdfgroup.org.

3

You (allmost certainly) did not close all of the opened and created HDF5 objects.

  True. If you want H5Fclose() to close open HDF5 objects in that file, you should take a look at using H5Pset_fclose_degree() when you open the file.

  Quincey

···

On May 14, 2009, at 6:12 AM, Werner Benger wrote:

Besides, having H5close() in a file reader's destructor will close the
library for each file. Should you have more than one file in your app,
such is likely to lead to the crashes described before.

  Werner

On Thu, 14 May 2009 04:54:24 -0500, Ramakrishnan Iyer <ramakrishnan.iyer@altair.com > > wrote:

All,

I have a hdf5 reader . I load a hdf5 file . After Loading the hdf5 file
, the file is close using H5Fclose . In the destructor of the Reader I
have a call to H5garbage_collect . Now I want to delete the hdf5 file .
But I am not able to delete the file unless , I have a call to H5close()
in the Reader's destructor . Why is it so ?

Regards

Ram

--
___________________________________________________________________________
Dr. Werner Benger <werner@cct.lsu.edu> Visualization Research
Laboratory for Creative Arts and Technology (LCAT)
Center for Computation & Technology at Louisiana State University (CCT/LSU)
239 Johnston Hall, Baton Rouge, Louisiana 70803
Tel.: +1 225 578 4809 Fax.: +1 225 578-5362

----------------------------------------------------------------------
This mailing list is for HDF software users discussion.
To subscribe to this list, send a message to hdf-forum-subscribe@hdfgroup.org.
To unsubscribe, send a message to hdf-forum-unsubscribe@hdfgroup.org.

----------------------------------------------------------------------
This mailing list is for HDF software users discussion.
To subscribe to this list, send a message to hdf-forum-subscribe@hdfgroup.org.
To unsubscribe, send a message to hdf-forum-unsubscribe@hdfgroup.org.

4

(This reply was certainly meant to go to the forum)

···

------- Forwarded message -------
From: "Ger van Diepen" <diepen@astron.nl>
To: "Werner Benger" <werner@cct.lsu.edu>
Cc:
Subject: Re: [hdf-forum] Again on H5close
Date: Thu, 14 May 2009 07:24:52 -0500

It looks as if we are talking C++ here.
IMHO it is much better to make simple classes like HDFGroup, HDFFile, etc.
keeping the hid internally. Their destructors should call the appropriate
close function.
In this way you do not have to worry about closing HDF objects. It's done
for you when the object goes out of scope. What's more important, in case
of exceptions they are automatically closed for you, so no hid leaks or so.

    // <synopsis>
    // This class wraps an HDF5 file hid (hdf5 id). It offers two benefits:
    // <ul>
    // <li> The most important is resource management. In case of an
exception,
    // the hid will automatically be closed by the destructor.
    // <li> A hid is a kind of pointer and should not be copied. This class
    // forbid making a copy, but make it possible to use it in a
    // shared pointer context.
    // </ul>
    // </synopsis>
    class HDFFile
    {
    public:
      // Default constructor sets hid to invalid.
      HDFFile()
        : itsHid(-1) {}
      // Construct from given hid.
      HDFFile (hid_t hid)
        : itsHid(hid) {}
      // The destructor closes the hid.
      ~HDF5HidAttribute()
        { close(); }
      // Close the hid if valid.
      void close();
      // Put hid in it. If it already contains a hid, it will be closed.
      void operator= (hid_t hid)
        { close(); itsHid = hid; }
      // Get the hid.
      hid_t hid() const
        { return itsHid; }
      // Convert automatically to hid_t.
      operator hid_t() const
        { return itsHid; }
    private:
      // Copy constructor cannot be used.
      HDFFile (const HDFFile& that);
      // Assignment cannot be used.
      HDFFile& operator= (const HDFFile& that);

      hid_t itsHid;
    };

The same for HDFGroup, HDFDataSet, etc.
I would even be better to have a base class HDFObject keeping the hid.

It could be used like:
   {
    HDFFile hfile(H5Fopen(...));
    HDFGroup hgroup(H5Gopen(hfile, ....))
        .. other code ..
   } // out-of-scope thus group and file get closed

I've done something like this and it works very nicely.

Cheers,
Ger

"Werner Benger" <werner@cct.lsu.edu> 05/14/09 1:12 PM >>>

You (allmost certainly) did not close all of the opened and created HDF5
objects.

Besides, having H5close() in a file reader's destructor will close the
library for each file. Should you have more than one file in your app,
such is likely to lead to the crashes described before.

  Werner

On Thu, 14 May 2009 04:54:24 -0500, Ramakrishnan Iyer <ramakrishnan.iyer@altair.com> wrote:

All,

I have a hdf5 reader . I load a hdf5 file . After Loading the hdf5 file
, the file is close using H5Fclose . In the destructor of the Reader I
have a call to H5garbage_collect . Now I want to delete the hdf5 file .
But I am not able to delete the file unless , I have a call to H5close()
in the Reader's destructor . Why is it so ?

Regards

Ram

--
___________________________________________________________________________
Dr. Werner Benger <werner@cct.lsu.edu> Visualization Research
Laboratory for Creative Arts and Technology (LCAT)
Center for Computation & Technology at Louisiana State University (CCT/LSU)
239 Johnston Hall, Baton Rouge, Louisiana 70803
Tel.: +1 225 578 4809 Fax.: +1 225 578-5362

----------------------------------------------------------------------
This mailing list is for HDF software users discussion.
To subscribe to this list, send a message to hdf-forum-subscribe@hdfgroup.org.
To unsubscribe, send a message to hdf-forum-unsubscribe@hdfgroup.org.

5

Hi Werner

as I wrote in another opportunity, I close all objects on my own before
closing a file. I only wish I could go with C++ alone, but unfortunately I
need a C toolkit which is then used to create HDF5 objects and managed by
C++ classes. So when I close a file object, I use H5Fget_obj_count for each
kind of object and close them all one by one.

HTH

-- ds

···

2009/5/14 Werner Benger <werner@cct.lsu.edu>

(This reply was certainly meant to go to the forum)

------- Forwarded message -------
From: "Ger van Diepen" <diepen@astron.nl>
To: "Werner Benger" <werner@cct.lsu.edu>
Cc:
Subject: Re: [hdf-forum] Again on H5close
Date: Thu, 14 May 2009 07:24:52 -0500

It looks as if we are talking C++ here.
IMHO it is much better to make simple classes like HDFGroup, HDFFile, etc.
keeping the hid internally. Their destructors should call the appropriate
close function.
In this way you do not have to worry about closing HDF objects. It's done
for you when the object goes out of scope. What's more important, in case
of exceptions they are automatically closed for you, so no hid leaks or so.

  // <synopsis>
  // This class wraps an HDF5 file hid (hdf5 id). It offers two benefits:
  // <ul>
  // <li> The most important is resource management. In case of an
exception,
  // the hid will automatically be closed by the destructor.
  // <li> A hid is a kind of pointer and should not be copied. This class
  // forbid making a copy, but make it possible to use it in a
  // shared pointer context.
  // </ul>
  // </synopsis>
  class HDFFile
  {
  public:
    // Default constructor sets hid to invalid.
    HDFFile()
      : itsHid(-1) {}
    // Construct from given hid.
    HDFFile (hid_t hid)
      : itsHid(hid) {}
    // The destructor closes the hid.
    ~HDF5HidAttribute()
      { close(); }
    // Close the hid if valid.
    void close();
    // Put hid in it. If it already contains a hid, it will be closed.
    void operator= (hid_t hid)
      { close(); itsHid = hid; }
    // Get the hid.
    hid_t hid() const
      { return itsHid; }
    // Convert automatically to hid_t.
    operator hid_t() const
      { return itsHid; }
  private:
    // Copy constructor cannot be used.
    HDFFile (const HDFFile& that);
    // Assignment cannot be used.
    HDFFile& operator= (const HDFFile& that);

    hid_t itsHid;
  };

The same for HDFGroup, HDFDataSet, etc.
I would even be better to have a base class HDFObject keeping the hid.

It could be used like:
{
  HDFFile hfile(H5Fopen(...));
  HDFGroup hgroup(H5Gopen(hfile, ....))
      .. other code ..
} // out-of-scope thus group and file get closed

I've done something like this and it works very nicely.

Cheers,
Ger

"Werner Benger" <werner@cct.lsu.edu> 05/14/09 1:12 PM >>>

You (allmost certainly) did not close all of the opened and created HDF5

objects.

Besides, having H5close() in a file reader's destructor will close the
library for each file. Should you have more than one file in your app,
such is likely to lead to the crashes described before.

       Werner

On Thu, 14 May 2009 04:54:24 -0500, Ramakrishnan Iyer > <ramakrishnan.iyer@altair.com> wrote:

All,

I have a hdf5 reader . I load a hdf5 file . After Loading the hdf5 file
, the file is close using H5Fclose . In the destructor of the Reader I
have a call to H5garbage_collect . Now I want to delete the hdf5 file .
But I am not able to delete the file unless , I have a call to H5close()
in the Reader's destructor . Why is it so ?

Regards

Ram

--
___________________________________________________________________________
Dr. Werner Benger <werner@cct.lsu.edu> Visualization
Research
Laboratory for Creative Arts and Technology (LCAT)
Center for Computation & Technology at Louisiana State University (CCT/LSU)
239 Johnston Hall, Baton Rouge, Louisiana 70803
Tel.: +1 225 578 4809 Fax.: +1 225 578-5362

----------------------------------------------------------------------
This mailing list is for HDF software users discussion.
To subscribe to this list, send a message to
hdf-forum-subscribe@hdfgroup.org.
To unsubscribe, send a message to hdf-forum-unsubscribe@hdfgroup.org.

6

Hi Dimitris & others,

  when using HDF5 in a C++ context, one needs to be aware that copying C++ objects
containing hid_t's requires special care; HDF5 does internal reference counting
for its hid_t's, and each time a duplicate of an hid_t is created by a copy or
assignment constructor this reference count needs to be adjusted. There is an
HDF5 API functions doing that. The HDF5 C++ API does something similar, but on
its own, since it was introduced before these HDF5 reference counting functions
were introduced (as far a I know, but I haven't looked at the HDF5 C++ API for
a while).

I would imagine that using H5Fget_obj_count() is more like a "brute force"
method to really close an object, even if it is yet kept open by other
hid_t's that have not been closed...?

  Werner

···

On Thu, 14 May 2009 10:35:10 -0500, Dimitris Servis <servisster@gmail.com> wrote:

Hi Werner

as I wrote in another opportunity, I close all objects on my own before
closing a file. I only wish I could go with C++ alone, but unfortunately I
need a C toolkit which is then used to create HDF5 objects and managed by
C++ classes. So when I close a file object, I use H5Fget_obj_count for each
kind of object and close them all one by one.

HTH

-- ds

2009/5/14 Werner Benger <werner@cct.lsu.edu>

(This reply was certainly meant to go to the forum)

------- Forwarded message -------
From: "Ger van Diepen" <diepen@astron.nl>
To: "Werner Benger" <werner@cct.lsu.edu>
Cc:
Subject: Re: [hdf-forum] Again on H5close
Date: Thu, 14 May 2009 07:24:52 -0500

It looks as if we are talking C++ here.
IMHO it is much better to make simple classes like HDFGroup, HDFFile, etc.
keeping the hid internally. Their destructors should call the appropriate
close function.
In this way you do not have to worry about closing HDF objects. It's done
for you when the object goes out of scope. What's more important, in case
of exceptions they are automatically closed for you, so no hid leaks or so.

  // <synopsis>
  // This class wraps an HDF5 file hid (hdf5 id). It offers two benefits:
  // <ul>
  // <li> The most important is resource management. In case of an
exception,
  // the hid will automatically be closed by the destructor.
  // <li> A hid is a kind of pointer and should not be copied. This class
  // forbid making a copy, but make it possible to use it in a
  // shared pointer context.
  // </ul>
  // </synopsis>
  class HDFFile
  {
  public:
    // Default constructor sets hid to invalid.
    HDFFile()
      : itsHid(-1) {}
    // Construct from given hid.
    HDFFile (hid_t hid)
      : itsHid(hid) {}
    // The destructor closes the hid.
    ~HDF5HidAttribute()
      { close(); }
    // Close the hid if valid.
    void close();
    // Put hid in it. If it already contains a hid, it will be closed.
    void operator= (hid_t hid)
      { close(); itsHid = hid; }
    // Get the hid.
    hid_t hid() const
      { return itsHid; }
    // Convert automatically to hid_t.
    operator hid_t() const
      { return itsHid; }
  private:
    // Copy constructor cannot be used.
    HDFFile (const HDFFile& that);
    // Assignment cannot be used.
    HDFFile& operator= (const HDFFile& that);

    hid_t itsHid;
  };

The same for HDFGroup, HDFDataSet, etc.
I would even be better to have a base class HDFObject keeping the hid.

It could be used like:
{
  HDFFile hfile(H5Fopen(...));
  HDFGroup hgroup(H5Gopen(hfile, ....))
      .. other code ..
} // out-of-scope thus group and file get closed

I've done something like this and it works very nicely.

Cheers,
Ger

"Werner Benger" <werner@cct.lsu.edu> 05/14/09 1:12 PM >>>

You (allmost certainly) did not close all of the opened and created HDF5

objects.

Besides, having H5close() in a file reader's destructor will close the
library for each file. Should you have more than one file in your app,
such is likely to lead to the crashes described before.

       Werner

On Thu, 14 May 2009 04:54:24 -0500, Ramakrishnan Iyer >> <ramakrishnan.iyer@altair.com> wrote:

All,

I have a hdf5 reader . I load a hdf5 file . After Loading the hdf5 file
, the file is close using H5Fclose . In the destructor of the Reader I
have a call to H5garbage_collect . Now I want to delete the hdf5 file .
But I am not able to delete the file unless , I have a call to H5close()
in the Reader's destructor . Why is it so ?

Regards

Ram

--
___________________________________________________________________________
Dr. Werner Benger <werner@cct.lsu.edu> Visualization
Research
Laboratory for Creative Arts and Technology (LCAT)
Center for Computation & Technology at Louisiana State University (CCT/LSU)
239 Johnston Hall, Baton Rouge, Louisiana 70803
Tel.: +1 225 578 4809 Fax.: +1 225 578-5362

----------------------------------------------------------------------
This mailing list is for HDF software users discussion.
To subscribe to this list, send a message to
hdf-forum-subscribe@hdfgroup.org.
To unsubscribe, send a message to hdf-forum-unsubscribe@hdfgroup.org.

--
___________________________________________________________________________
Dr. Werner Benger <werner@cct.lsu.edu> Visualization Research
Laboratory for Creative Arts and Technology (LCAT)
Center for Computation & Technology at Louisiana State University (CCT/LSU)
239 Johnston Hall, Baton Rouge, Louisiana 70803
Tel.: +1 225 578 4809 Fax.: +1 225 578-5362

----------------------------------------------------------------------
This mailing list is for HDF software users discussion.
To subscribe to this list, send a message to hdf-forum-subscribe@hdfgroup.org.
To unsubscribe, send a message to hdf-forum-unsubscribe@hdfgroup.org.

7

Hi Werner,

you are of course right if you assume a C++ wrapping of HDF5 API. If you
consider wrapping your own API where one function may open many handles, in
case of an exception you should close many handles for one file that are
left open. In principle using H5Fget_obj_count() when an exception is
thrown makes sure you can really close the file handle, otherwise it will
remain open.

BR

-- dimitris

···

2009/5/14 Werner Benger <werner@cct.lsu.edu>

Hi Dimitris & others,

when using HDF5 in a C++ context, one needs to be aware that copying C++
objects
containing hid_t's requires special care; HDF5 does internal reference
counting
for its hid_t's, and each time a duplicate of an hid_t is created by a copy
or
assignment constructor this reference count needs to be adjusted. There is
an
HDF5 API functions doing that. The HDF5 C++ API does something similar, but
on
its own, since it was introduced before these HDF5 reference counting
functions
were introduced (as far a I know, but I haven't looked at the HDF5 C++ API
for
a while).

I would imagine that using H5Fget_obj_count() is more like a "brute force"
method to really close an object, even if it is yet kept open by other
hid_t's that have not been closed...?

       Werner

On Thu, 14 May 2009 10:35:10 -0500, Dimitris Servis <servisster@gmail.com> > wrote:

Hi Werner

as I wrote in another opportunity, I close all objects on my own before
closing a file. I only wish I could go with C++ alone, but unfortunately I
need a C toolkit which is then used to create HDF5 objects and managed by
C++ classes. So when I close a file object, I use H5Fget_obj_count for
each
kind of object and close them all one by one.

HTH

-- ds

2009/5/14 Werner Benger <werner@cct.lsu.edu>

(This reply was certainly meant to go to the forum)

------- Forwarded message -------
From: "Ger van Diepen" <diepen@astron.nl>
To: "Werner Benger" <werner@cct.lsu.edu>
Cc:
Subject: Re: [hdf-forum] Again on H5close
Date: Thu, 14 May 2009 07:24:52 -0500

It looks as if we are talking C++ here.
IMHO it is much better to make simple classes like HDFGroup, HDFFile,
etc.
keeping the hid internally. Their destructors should call the appropriate
close function.
In this way you do not have to worry about closing HDF objects. It's done
for you when the object goes out of scope. What's more important, in case
of exceptions they are automatically closed for you, so no hid leaks or
so.

// <synopsis>
// This class wraps an HDF5 file hid (hdf5 id). It offers two benefits:
// <ul>
// <li> The most important is resource management. In case of an
exception,
// the hid will automatically be closed by the destructor.
// <li> A hid is a kind of pointer and should not be copied. This class
// forbid making a copy, but make it possible to use it in a
// shared pointer context.
// </ul>
// </synopsis>
class HDFFile
{
public:
   // Default constructor sets hid to invalid.
   HDFFile()
     : itsHid(-1) {}
   // Construct from given hid.
   HDFFile (hid_t hid)
     : itsHid(hid) {}
   // The destructor closes the hid.
   ~HDF5HidAttribute()
     { close(); }
   // Close the hid if valid.
   void close();
   // Put hid in it. If it already contains a hid, it will be closed.
   void operator= (hid_t hid)
     { close(); itsHid = hid; }
   // Get the hid.
   hid_t hid() const
     { return itsHid; }
   // Convert automatically to hid_t.
   operator hid_t() const
     { return itsHid; }
private:
   // Copy constructor cannot be used.
   HDFFile (const HDFFile& that);
   // Assignment cannot be used.
   HDFFile& operator= (const HDFFile& that);

   hid_t itsHid;
};

The same for HDFGroup, HDFDataSet, etc.
I would even be better to have a base class HDFObject keeping the hid.

It could be used like:
{
HDFFile hfile(H5Fopen(...));
HDFGroup hgroup(H5Gopen(hfile, ....))
     .. other code ..
} // out-of-scope thus group and file get closed

I've done something like this and it works very nicely.

Cheers,
Ger

"Werner Benger" <werner@cct.lsu.edu> 05/14/09 1:12 PM >>>

You (allmost certainly) did not close all of the opened and created

HDF5

objects.

Besides, having H5close() in a file reader's destructor will close the
library for each file. Should you have more than one file in your app,
such is likely to lead to the crashes described before.

      Werner

On Thu, 14 May 2009 04:54:24 -0500, Ramakrishnan Iyer >>> <ramakrishnan.iyer@altair.com> wrote:

All,

I have a hdf5 reader . I load a hdf5 file . After Loading the hdf5 file
, the file is close using H5Fclose . In the destructor of the Reader I
have a call to H5garbage_collect . Now I want to delete the hdf5 file .
But I am not able to delete the file unless , I have a call to H5close()
in the Reader's destructor . Why is it so ?

Regards

Ram

--

___________________________________________________________________________
Dr. Werner Benger <werner@cct.lsu.edu> Visualization
Research
Laboratory for Creative Arts and Technology (LCAT)
Center for Computation & Technology at Louisiana State University
(CCT/LSU)
239 Johnston Hall, Baton Rouge, Louisiana 70803
Tel.: +1 225 578 4809 Fax.: +1 225 578-5362

----------------------------------------------------------------------
This mailing list is for HDF software users discussion.
To subscribe to this list, send a message to
hdf-forum-subscribe@hdfgroup.org.
To unsubscribe, send a message to hdf-forum-unsubscribe@hdfgroup.org.

--
___________________________________________________________________________
Dr. Werner Benger <werner@cct.lsu.edu> Visualization
Research
Laboratory for Creative Arts and Technology (LCAT)
Center for Computation & Technology at Louisiana State University (CCT/LSU)
239 Johnston Hall, Baton Rouge, Louisiana 70803
Tel.: +1 225 578 4809 Fax.: +1 225 578-5362