2006.09.22 19:18 "Re: [Tiff] libjpeg", by Joris Van Damme
So I'm left with two questions
- Is the longjmp system really unsafe? I mean nowadays, on most systems, as opposed to being unsafe on one or two systems a decade ago.
- If this really is an issue, are exceptions a good alternative? Or do Linux guys not have exceptions? Are exceptions portable?
A possible solution is for libtiff to become aware of operating system semaphores/mutexes and carefully use locks to ensure that the problem APIs are invoked safely.
I've recently added some LUTs in color convertions in LibTiff, used by the RGBA interface. That was another instance where it would have been good for LibTiff to 'become aware of operation system semaphores/mutexes' (critical sections would be most useful on Win32 for this particular purpose). Since it's not, and since I didn't want to sacrifice thread safety, the LUTs are calculated the first time they're needed in the context, as opposed to the first time they're needed in the process. This results in needless recalculation.
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.
Besides, I'm not convinced this is a proper solution, for two reasons.
- It's overkill. You'd be serializing complete LibJpeg calls, while actual core of that calls is threadsafe and only longjump encapsulator might not be. I think it is extremely important to keep synchronisation bottlenecks lean as possible.
- 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?
Libtiff itself is not compiled to ensure thread safety on many platforms since often special compilation flags are required in order to ensure that thread safe interfaces are used. For example, a thread-safe build may use a thread-specific errno (accessed via functions) while the default build may use a simple global integer. This is also a platform dependent issue.
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?
It goes without saying that any platform specific layer needs to be examined separately. In theory at least, the platform specific layers included with LibTiff aren't necessarilly the only ones that are being used. If any one of these, or any application layer specific error handler, uses a global variable to temporarilly store error codes, it messes up thread safety.
I believe you should regard that separately, though. Otherwise, no library with any sorts of callback hook at any place could ever be said to be thread-safe, as the callback implementation could do thread-unsafe stuff. Hence, my consistent warning that 'thread-safe' is not synonimus to 'fool-proof', i.e. the calling and callback logic must still make sense.
Is this at all related to the above quote? If not, please elaborate. If I did understand you correctly, then we ought to regard this in particular as off-topic, i.e. unrelated to the thread-safeness of LibTiff itself.
Joris Van Damme
Download your free TIFF tag viewer for windows here: