| AWARE [SYSTEMS] | Imaging expertise for the Delphi developer | |||||||
![]() |
TIFF and LibTiff Mailing List Archive | |||||||
LibTiff Mailing List
TIFF and LibTiff Mailing List Archive Contact
The TIFF Mailing List Homepage |
Thread2010.06.17 19:35 "Re: libtiff 4 API/ABI stability?", by Olivier PaquetOn Thu, Jun 17, 2010 at 2:47 PM, Bob Friesenhahn <bfriesen@simple.dallas.tx.us> 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" But you still need to pass the application handle to every TIFFOpen() call. This might be a better solution as it is more easily extensible. If some new piece of "global" state comes up in the future, we can add a call to set it in the "application handle" instead of creating a third version of TIFFOpen(). > 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). And more. Take autodesk maya: ldd `which maya.bin` | wc -l 122 and this just the starting point as many more will be loaded dynamically as plug-ins. No one really knows how many users of libtiff are in there or where error messages will end up. > 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 Yes, TSD is probably the only thing that really scales. The downside is that it means we have to link with libpthread on linux. I'm not sure if that kind of change can safely be made once 4.0 is released so now might be a good time, even if we don't actually use libpthread yet. Olivier |
|||||||