2000.03.16 13:20 "-D_REENTRANT for libtiff and jpeg?", by Ivo Penzar

2000.03.16 13:20 "-D_REENTRANT for libtiff and jpeg?", by Ivo Penzar

For our cross-platform project on 9x/NT/2K, Linux and Sun (should also work on others, we didn't test yet) we use the libtiff and jpeg (The JPEG Independent Group) open source libraries. Thanks to their authors and to this group.

It is our Java image viewer (and another, Visual C++ based) which uses our "native code" (C++) imaging dynamic/shared library to read/write/manipulate TIFF, JPEG, BMP, GIF, and CALS images. This library then, for the low-level TIFF and JPEG read/write operations, calls to the libtiff and jpeg libraries...

That our topmost library successfully handles the multithreading and locking of individual image objects. I.e., two threads could never access the same image object (and hence, the same tiffinfo or jpeg_decompress_struct), but two different threads could probably work concurrently on two different tiff or jpeg images.

My basic CLockable class (to provide a platform-independent interface and to hide its platform-dependent implementation) is actually built on top of WIN32 mutexes (NT), POSIX threads (Linux, Unix) and native threads (Solaris). Thus we build the libtiff/libjpeg as Multithreading dll on Windows, i.e., with _REENTRANT macro defined on Solaris.

So far, so good (almost). Nevertheless, I am still not complitely sure if there could be some non-reentrant functions or static variables deep into the libtiff or jpeg libraries?

Does anybody else have some good or bad expirience with the libtiff and jpeg libraries in such a multithreading environments? Or knows of some particular functions which are not reentrant. Or has a proven knowledge (based on the source-code inspection) that everything those libraries do for reading/writing is properly localized into the corresponding tiffinfo and jpeg_decompress_struct/jpeg_compress_struct structures.

Thanks for your opinions.

Ivo