2006.09.22 20:09 "Re: [Tiff] libjpeg", by Bob Friesenhahn

However, it would be quite a considerable operation. We'd need to define initialization, finalization, lock and unlock calls, and need to resolve these in every platform specific unit like tif_win32.c and the sorts.

It is not too terribly bad since it turns out that there are only two dominant thread APIs (WIN32 and POSIX).

It's underkill, possibly. I can't pretend I know any gory details on the longjump stuff and need to rely on you to fill the gaps, but doing so you should consider other threads may be simultaniously using longjump stuff in completely unrelated matters. That means part of the longjump usage would be protected by some mutex (the part inside tif_jpeg and tif_ojpeg), but other parts are not or either are protected by other mutexes of their own. Is that safe?

As far as I am aware, setjmp() stores all the data it needs in the user-supplied jmp_buf buffer. Conceivably a platform could store just a handle there and there would be additional thread safety issues but that seems unlikely. The most likely issue is that the context stored by setjmp() is no longer valid, or is incomplete, when longjmp() is invoked. So I would not worry about other setjmp()/longjmp() users.

errno? Are you refering to issues specific to any particular platform, like e.g. IO calls or memory allocation calls and their error returns? Or are you refering to a specific implementation of LibTiff error handlers?

errno was just an example. I see that libtiff only uses it for ATARI even though errno is the POSIX standard way to return an error code from a system call. Another area usually effected by thread-safe compilation are the stdio APIs.

Regardless of thread safety issues, few complaints have been voiced about improper libtiff operation due to multi-threaded use. This explains why libtiff has not been enhanced to positively ensure thread safety.

Bob
======================================
Bob Friesenhahn
bfriesen@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer, http://www.GraphicsMagick.org/