LibTiff Mailing List
TIFF and LibTiff Mailing List Archive
June 2010
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
Thread
2010.06.17 18:09 "Re: 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! Adam