2010.06.17 17:15 "Re: [Tiff] libtiff 4 API/ABI stability?", by Adam Goode

On 06/17/2010 12:55 PM, Bob Friesenhahn wrote:

Yeah, getting rid of globals is a great thing to do. I started to look at this some months ago: which globals are you interested in eliminating? I had an idea for introducing new API calls that don't use various globals so that new code could be safe, while old code could still work as before.

There may be more, but the ones I noticed are related to the error/warning handlers. These handlers are not thread safe.

There are also some non-const static variables used in the library.

It would be good to decide if libtiff should be thread safe. If so, everything needs to be naturally re-entrant, or support for locks needs to be added in a few places.

Yes! I would definitely love libtiff to be thread safe. The way I see it, there are 3 levels of thread safety:

libtiff API (but not TIFF structures) is usable from multiple threads at once.
TIFF structures open for reading are usable from multiple threads at once.
TIFF structures open for writing are usable from multiple threads at once.

#3 seems too hard and not worth the trouble. #1 is definitely important and should be done. #2 would be nice, would take more work, is doable, but is not urgent.

I say we aim for #1. This is important, not just for multiple threads, but for multiple unrelated functions accessing libtiff from the same memory space. In my library that uses libtiff (OpenSlide), I have to avoid setting the error/warning callbacks in case the application has changed them. I would like to be able to set these in my code without interfering with the application's intent.

Also, for globals, there is also codec registration.

See my old mail for my idea: http://www.asmail.be/msg0054681986.html

Adam