2017.07.05 18:51 "Re: [Tiff] A bug in libtiff error/warning handling", by Paavo Helde

On 5.07.2017 18:02, Olivier Paquet wrote:

The other thing to be decided is if we want to push the idea further to have a library handle so we can also fix TIFFRegisterCODEC(), TIFFSetTagExtender(), etc. Such a handle could hold all currently global data and would be given to the new TIFFOpen. A little more complexity but also potentially a more complete long term fix.

Do you mean two-step initialization, e.g. first creating an "engine" or something, then using this to open TIFF files? That would be very nice design! Different libraries (or a single library for that matter) could then create multiple "engines" which would be totally independent. Future extensions could be added by new API functions which modify the engine object.

It should be clearly defined if and how this engine can be accessed from multiple threads. If it can, then it must not require any external or internal locking when processing the actual TIFF files - if the client wants to read or write 20 different TIFF files in parallel, the library should support that. Probably the simplest way to achieve that is to require that the client does not access the engine in other threads when calling mutator methods like TIFFRegisterCODEC().

Paavo