Hey guys, I've been working with some friends who are trying to get HDF5
1.8.x packaged up for debian/ubuntu, and at issue is the conflict
between --enable-cxx and --enable-threadsafe in the 1.8.x series.
I know I've talked to people before and received answers from "We're not
sure" to "Just disable the check in the configure.ac". Fedora just
hacked up the configure and ships with threadsafe-enabled c++ libs. I'm
hoping people have another recommendation, as the Debian packagers are
wary of deviating from upstream too much. And of course, shipping a
separate thread-safe and non-thread-safe HDF5 lib such that we can then
also ship the c++ non-thread-safe lib seems really suboptimal.
Thanks,
...Eric
···
----------------------------------------------------------------------
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.
Hi Eric,
Hey guys, I've been working with some friends who are trying to get HDF5
1.8.x packaged up for debian/ubuntu, and at issue is the conflict
between --enable-cxx and --enable-threadsafe in the 1.8.x series.
I know I've talked to people before and received answers from "We're not
sure" to "Just disable the check in the configure.ac". Fedora just
hacked up the configure and ships with threadsafe-enabled c++ libs. I'm
hoping people have another recommendation, as the Debian packagers are
wary of deviating from upstream too much. And of course, shipping a
separate thread-safe and non-thread-safe HDF5 lib such that we can then
also ship the c++ non-thread-safe lib seems really suboptimal.
The threadsafety in the HDF5 library is implemented by grabbing a mutex whenever a thread enters a C API routine. However, there is no equivalent mutex for the C++ (or FORTRAN) API wrappers. Because those wrappers generate objects which are not safe from getting smashed by multiple threads, we ship the HDF5 library with the configure script detecting and preventing users from enabling both of those configure flags. I wouldn't consider it safe for a distribution to ship with both options enabled, since it requires an application developer to put wrappers (or some other threadsafety mechanism) around the HDF5 C++ objects before the C++ API can be used in a threaded application.
Quincey
···
On Jun 17, 2009, at 10:52 AM, Eric Jonas wrote:
Ahh, so the point is that it appears that your concerns are that
--enable-threadsafe will be interpreted as implying that the C++ api
wrappers are threadsafe, when in reality it's just the underlying C API
that would be thread safe, and additional effort would be necessary to
have the c++ bindings be thread safe.
The problem is that at the moment this means that a distribution either
has to abandon thread safe options entirely (and there are presumably
some applications / users of the C interface that depend on this thread
safety guarantee) or abandon the C++ bindings entirely (and there are
applications, such as my own, which depend on the C++ libs, but not in a
thread-safe capacity).
Would it not be preferable to let you build the c++ option with
--enable-threadsafe, but just have a warning in the c++ docs that the C
++ bindings themselves are not thread safe? C++ programmers are used to
having various higher-level libraries have differing (let's say
"nuanced") thread-safety guarantees, from the STL on down (up?).
...Eric
···
On Wed, 2009-06-17 at 15:21 -0500, Quincey Koziol wrote:
Hi Eric,
On Jun 17, 2009, at 10:52 AM, Eric Jonas wrote:
> Hey guys, I've been working with some friends who are trying to get
> HDF5
> 1.8.x packaged up for debian/ubuntu, and at issue is the conflict
> between --enable-cxx and --enable-threadsafe in the 1.8.x series.
>
> I know I've talked to people before and received answers from "We're
> not
> sure" to "Just disable the check in the configure.ac". Fedora just
> hacked up the configure and ships with threadsafe-enabled c++ libs.
> I'm
> hoping people have another recommendation, as the Debian packagers are
> wary of deviating from upstream too much. And of course, shipping a
> separate thread-safe and non-thread-safe HDF5 lib such that we can
> then
> also ship the c++ non-thread-safe lib seems really suboptimal.
The threadsafety in the HDF5 library is implemented by grabbing a
mutex whenever a thread enters a C API routine. However, there is no
equivalent mutex for the C++ (or FORTRAN) API wrappers. Because those
wrappers generate objects which are not safe from getting smashed by
multiple threads, we ship the HDF5 library with the configure script
detecting and preventing users from enabling both of those configure
flags. I wouldn't consider it safe for a distribution to ship with
both options enabled, since it requires an application developer to
put wrappers (or some other threadsafety mechanism) around the HDF5 C+
+ objects before the C++ API can be used in a threaded application.
Quincey
Hi Eric,
Hi Eric,
Hey guys, I've been working with some friends who are trying to get
HDF5
1.8.x packaged up for debian/ubuntu, and at issue is the conflict
between --enable-cxx and --enable-threadsafe in the 1.8.x series.
I know I've talked to people before and received answers from "We're
not
sure" to "Just disable the check in the configure.ac". Fedora just
hacked up the configure and ships with threadsafe-enabled c++ libs.
I'm
hoping people have another recommendation, as the Debian packagers are
wary of deviating from upstream too much. And of course, shipping a
separate thread-safe and non-thread-safe HDF5 lib such that we can
then
also ship the c++ non-thread-safe lib seems really suboptimal.
The threadsafety in the HDF5 library is implemented by grabbing a
mutex whenever a thread enters a C API routine. However, there is no
equivalent mutex for the C++ (or FORTRAN) API wrappers. Because those
wrappers generate objects which are not safe from getting smashed by
multiple threads, we ship the HDF5 library with the configure script
detecting and preventing users from enabling both of those configure
flags. I wouldn't consider it safe for a distribution to ship with
both options enabled, since it requires an application developer to
put wrappers (or some other threadsafety mechanism) around the HDF5 C+
+ objects before the C++ API can be used in a threaded application.
Quincey
Ahh, so the point is that it appears that your concerns are that
--enable-threadsafe will be interpreted as implying that the C++ api
wrappers are threadsafe, when in reality it's just the underlying C API
that would be thread safe, and additional effort would be necessary to
have the C++ bindings be thread safe.
Yes, exactly.
The problem is that at the moment this means that a distribution either
has to abandon thread safe options entirely (and there are presumably
some applications / users of the C interface that depend on this thread
safety guarantee) or abandon the C++ bindings entirely (and there are
applications, such as my own, which depend on the C++ libs, but not in a
thread-safe capacity).
These are certainly valid use cases. 
Would it not be preferable to let you build the c++ option with
--enable-threadsafe, but just have a warning in the c++ docs that the C
++ bindings themselves are not thread safe? C++ programmers are used to
having various higher-level libraries have differing (let's say
"nuanced") thread-safety guarantees, from the STL on down (up?).
Well, we tried it that way for a long time and it generated a lot of questions to our helpdesk, so eventually we just took the gun off the table, so people couldn't shoot themselves in the foot (so to speak :-). I'd actually prefer to make the C++ bindings thread safe... :-/ It's not a _huge_ amount of work, but our time is tied up with other projects currently. Patches from knowledgeable folks in the community would be welcome...
Quincey
···
On Jun 17, 2009, at 3:39 PM, Eric Jonas wrote:
On Wed, 2009-06-17 at 15:21 -0500, Quincey Koziol wrote:
On Jun 17, 2009, at 10:52 AM, Eric Jonas wrote:
