LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
September 2006
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
2006.09.22 20:09 "Re: libjpeg", by Bob Friesenhahn
On Fri, 22 Sep 2006, Joris wrote: > > 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). > 2) 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/