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