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

2017-07-05 9:57 GMT-04:00 Paavo Helde <paavo@osa.pri.ee>:
>
> On 5.07.2017 15:40, Olivier Paquet wrote:
>> By the way, thread local storage is a poor solution as it does not
>> handle the case of several unrelated libraries using libtiff from
>> within the same thread.
>
> This can be made to work if the client library installs and restores the
> handlers each time before/after any call to libTIFF. Yes that's tedious
> but better than the current state. Better fixes would mean API changes,
> like adding error/warning pointers to an enhanced version of
> TIFFClientOpen().

Yes, it would require API changes but I think they are needed. I don't
think we should add a dependency to get thread local storage which
provides only half a fix when there is a better fix which does not
require it. Both require changes to client code anyway.

Besides, it would also break some stuff. I'm fairly certain our own
code sets the error handler only once and expects it to be used by
multiple threads. I doubt we're the only ones doing that. A new
version of TIFFClientOpen() would allow that to keep working.

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.

Olivier