2010.06.17 18:04 "Re: [Tiff] libtiff 4 API/ABI stability?", by Olivier Paquet
On Thu, Jun 17, 2010 at 1:15 PM, Adam Goode <email@example.com> 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.
Also, for globals, there is also codec registration.
A quick grep also reveals:
- A few fields in tif_aux.c: TIFFVGetFieldDefaulted. These buffers could be put in the TIFF structure itself.
- 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?