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 19:36 "Re: A bug in libtiff error/warning handling", by Olivier Paquet

2017-07-05 14:51 GMT-04:00 Paavo Helde <paavo@osa.pri.ee>:
> 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.

Yes, that's exactly the idea. It's an explicit container for what are
currently global variables. And indeed even a single library could use
multiple copies, for example to install a different error handler for
every open file. That would make sense for a C++ object wanting to
keep a list of its own errors.

> 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().

I think a reasonable requirement is that nothing else is using it
while it is modified. TIFFOpen and everything else using the TIFF
handle should only have read-only access so multiple files can share
it. I think that's more or less how it is with current global
variables. And how you put it in your example.

Olivier