Quantcast

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

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Eric Jonas
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 at hdfgroup.org.
To unsubscribe, send a message to hdf-forum-unsubscribe at hdfgroup.org.




Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Quincey Koziol
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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2502 bytes
Desc: not available
URL: <http://mail.hdfgroup.org/pipermail/hdf-forum_hdfgroup.org/attachments/20090617/cd3a6c2e/attachment.bin>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[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









Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Quincey Koziol
Hi Eric,

On Jun 17, 2009, at 3:39 PM, Eric Jonas wrote:

> 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.

        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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2502 bytes
Desc: not available
URL: <http://mail.hdfgroup.org/pipermail/hdf-forum_hdfgroup.org/attachments/20090617/67654b41/attachment.bin>

Loading...