AWARE [SYSTEMS] Imaging expertise for the Delphi developer
AWare Systems, Imaging expertise for the Delphi developer, Home TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
July 2017

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



Valid HTML 4.01!



Thread

2017.07.04 11:04 "A bug in libtiff error/warning handling", by Paavo Helde
2017.07.04 11:30 "Re: A bug in libtiff error/warning handling", by Even Rouault
2017.07.04 12:20 "Re: A bug in libtiff error/warning handling", by <rleigh@codelibre.net>
2017.07.04 12:55 "Re: A bug in libtiff error/warning handling", by Even Rouault
2017.07.04 12:30 "Re: A bug in libtiff error/warning handling", by Paavo Helde
2017.07.04 18:38 "Re: A bug in libtiff error/warning handling", by Bob Friesenhahn
2017.07.04 19:31 "Re: A bug in libtiff error/warning handling", by Paavo Helde
2017.07.05 12:12 "Re: A bug in libtiff error/warning handling", by Edward Lam
2017.07.05 12:40 "Re: A bug in libtiff error/warning handling", by Olivier Paquet
2017.07.05 13:41 "Re: A bug in libtiff error/warning handling", by Bob Friesenhahn
2017.07.05 13:57 "Re: A bug in libtiff error/warning handling", by Paavo Helde
2017.07.05 15:02 "Re: A bug in libtiff error/warning handling", by Olivier Paquet
2017.07.05 18:51 "Re: A bug in libtiff error/warning handling", by Paavo Helde
2017.07.05 19:36 "Re: A bug in libtiff error/warning handling", by Olivier Paquet

2017.07.05 18:51 "Re: 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