[hdf-forum] HDF5 --enable-cxx --enable-threadsafe conflict, ubuntu/debian packages

[Eric Jonas]

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

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