AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

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



Valid HTML 4.01!



Thread

2006.09.22 14:20 "libjpeg", by Philip Watkinson
2006.09.22 14:31 "Re: libjpeg", by Bob Friesenhahn
2006.09.22 15:22 "Re: libjpeg", by Joris Van Damme
2006.09.22 16:31 "Re: libjpeg", by Bob Friesenhahn
2006.09.22 16:49 "Re: libjpeg", by Philip Watkinson
2006.09.22 17:09 "Re: libjpeg", by Bob Friesenhahn
2006.09.22 17:25 "Re: libjpeg", by Joris Van Damme
2006.09.23 00:51 "Re: libjpeg", by Graeme Gill
2006.09.23 01:45 "Re: libjpeg", by Bob Friesenhahn
2006.09.22 15:20 "Re: libjpeg", by Joris Van Damme
2006.09.22 16:42 "Re: libjpeg", by Bob Friesenhahn
2006.09.22 17:31 "Re: libjpeg", by Joris Van Damme
2006.09.22 18:09 "Re: libjpeg", by Toby Thain
2006.09.22 18:16 "Re: libjpeg", by Bob Friesenhahn
2006.09.22 19:21 "Re: libjpeg", by Joris Van Damme
2006.09.22 18:29 "Re: libjpeg", by Bob Friesenhahn
2006.09.22 19:18 "Re: libjpeg", by Joris Van Damme
2006.09.22 20:09 "Re: libjpeg", by Bob Friesenhahn
2006.09.22 20:21 "Re: libjpeg", by Joris Van Damme

2006.09.22 19:18 "Re: libjpeg", by Joris Van Damme

Bob,

> > So I'm left with two questions
> > 1) 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. 2) 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.

1) 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.
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?

> 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.


Best regards,

Joris Van Damme
info@awaresystems.be
http://www.awaresystems.be/
Download your free TIFF tag viewer for windows here:
http://www.awaresystems.be/imaging/tiff/astifftagviewer.html