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

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

On 06/17/2010 02:04 PM, Olivier Paquet wrote:

On Thu, Jun 17, 2010 at 1:15 PM, Adam Goode <adam@spicenitz.org> wrote:

>> 1. libtiff API (but not TIFF structures) is usable from multiple
>> threads at once.

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.

Agreed. In fact, #1 is probably already assumed by many users of the library. That's what we do anyway and it works out ok.

Yeah, it will work ok in 99% of cases. It won't work if one library needs to register a codec that changes the behavior of another library, for example. Not so much an issue if you're using libtiff from an application, but it is if you're writing a library that uses libtiff.

Also, for globals, there is also codec registration.

A quick grep also reveals:

  1. A few fields in tif_aux.c: TIFFVGetFieldDefaulted. These buffers could be put in the TIFF structure itself.
  2. A table in tif_luv.c: oog_encode(). In practice this can be fixed well enough without locks.

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

Seems like a fairly good solution as far as the API is concerned. It solves both multithread issues and multiple user issues. Is there an entry in bugzilla to track all this?

I don't think so. I'll get to it eventually, unless you beat me to it!