LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
June 2010
Previous Thread
Next Thread
Previous by Thread
Next by Thread
Previous by Date
Next by Date
Contact
The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems
Thread
2010.06.18 00:31 "Re: libtiff 4 API/ABI stability?", by Adam Goode
On 06/17/2010 02:47 PM, Bob Friesenhahn wrote: > On Thu, 17 Jun 2010, Adam Goode wrote: >> >> Yeah, it will work ok in 99% of cases. It won't work if one library >> needs to register a codec that changes the behavior of another library, >> for example. Not so much an issue if you're using libtiff from an >> application, but it is if you're writing a library that uses libtiff. > > In this case you would need to have an 'application' handle which > contains all application specific references, where a single "program" > could have multiple handles. Multiple users of libtiff in a single > application becomes more common as applications become huge and use many > other libraries (some apps seem to use over 70 libraries now). > Yes, that sounds about right. Though I don't think an application handle is strictly necessary, I would just pass the warning/error callbacks and codecs directly to TIFFOpen (following the Law of Demeter). Though putting it all together into an application handle is ok too. > I have seen very good success from using thread specific data (TSD), > which is supported under POSIX and Microsoft Windows, and is easily > emulated in a non-threaded build. TSD can be much more efficient than > using shared data with locking if the algorithm can get by with > different data per thread. There are also TSD compiler extensions for > GCC and MSVC but I would not want to use something non-portable like that. > Yeah, I definitely think locks are not the way to go. And I don't think they are necessary for implementing the kind thread safety we are looking for here. You just need to allocate a bit more on the heap and pass things in. libjpeg definitely does this right. Adam