LibTiff Mailing List

TIFF and LibTiff Mailing List Archive
November 2009

Previous Thread
Next Thread

Previous by Thread
Next by Thread

Previous by Date
Next by Date

The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems

2009.11.27 05:41 "v4.0 API feedback", by Adam Goode

Hi,

One thing I would really like to see in libtiff is a fully-reentrant
API. Currently, libtiff cannot be used independently from 2 different
callers in the same memory space. This is primarily in the error and
warning handlers, as well as codec registration.

I would like to start working on new APIs that take additional
parameters for currently static structs. I have not looked into it
fully, but this can be done without breaking compatibility by doing
something like this:

 1. Introduce TIFFGetBuiltinCODECs(), which returns a copy of all
    the built-in codecs. This list can be altered by the user,
    without affecting anything else (it is a private copy). This
    is how new codecs would be registered.
 2. Introduce TIFFOpen2, that takes a codec list as well as warning
    and error callback functions. Rework the code of TIFFOpen to
    implement this.
 3. Change TIFFOpen to just be a tiny function that calls TIFFOpen2
    with the old static codec list and error functions. Now things
    calling the old TIFFOpen will work as expected, but new code
    using TIFFOpen2 can register codecs privately and not worry
    about changing the behavior of other callers. More importantly,
    this now allows different threads to use different codecs and
    error functions.


Any thoughts? I think this is important, and I am willing to find some
time to start hacking on it.



Thanks,

Adam


P.S. There are a few non-API places where the library is non-reentrant,
specifically when doing TIFFGetField on WHITEPOINT and a few others.
This can be fixed without changing anything non-private. I am working on
some patches for these too.