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
June 2010

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

2010.06.17 15:39 "libtiff 4 API/ABI stability?", by Adam Goode
2010.06.17 16:21 "Re: libtiff 4 API/ABI stability?", by Edward Lam
2010.06.17 16:22 "Re: libtiff 4 API/ABI stability?", by Edward Lam
2010.06.17 16:38 "Re: libtiff 4 API/ABI stability?", by Adam Goode
2010.06.17 22:06 "Re: libtiff 4 API/ABI stability?", by Edward Lam
2010.06.18 00:13 "Re: libtiff 4 API/ABI stability?", by Adam Goode
2010.06.18 13:44 "Re: libtiff 4 API/ABI stability?", by Edward Lam
2010.06.18 17:46 "[PATCH] Build tif_win32.c on Windows except on Cygwin", by Adam Goode
2010.06.18 18:21 "Re: [PATCH] Build tif_win32.c on Windows except on Cygwin", by Bob Friesenhahn
2010.06.18 18:32 "Re: [PATCH] Build tif_win32.c on Windows except on Cygwin", by Adam Goode
2010.06.18 18:35 "Re: [PATCH] Build tif_win32.c on Windows except on Cygwin", by Adam Goode
2010.06.28 13:25 "Re: [PATCH] Build tif_win32.c on Windows except on Cygwin", by Edward Lam
2010.06.28 15:54 "Re: [PATCH] Build tif_win32.c on Windows except on Cygwin", by Bob Friesenhahn
2010.06.29 11:23 "Re: [PATCH] Build tif_win32.c on Windows except on Cygwin", by Andrey Kiselev
2010.06.29 13:46 "Re: [PATCH] Build tif_win32.c on Windows except on Cygwin", by Adam Goode
2010.06.17 16:28 "Re: libtiff 4 API/ABI stability?", by Bob Friesenhahn
2010.06.17 16:34 "Re: libtiff 4 API/ABI stability?", by Adam Goode
2010.06.17 16:55 "Re: libtiff 4 API/ABI stability?", by Bob Friesenhahn
2010.06.17 17:15 "Re: libtiff 4 API/ABI stability?", by Adam Goode
2010.06.17 18:04 "Re: libtiff 4 API/ABI stability?", by Olivier Paquet
2010.06.17 18:09 "Re: libtiff 4 API/ABI stability?", by Adam Goode
2010.06.17 18:47 "Re: libtiff 4 API/ABI stability?", by Bob Friesenhahn
2010.06.17 19:35 "Re: libtiff 4 API/ABI stability?", by Olivier Paquet
2010.06.18 00:33 "Re: libtiff 4 API/ABI stability?", by Adam Goode
2010.06.18 01:45 "Re: libtiff 4 API/ABI stability?", by Adam Goode
2010.06.18 01:54 "Re: libtiff 4 API/ABI stability?", by Olivier Paquet
2010.06.18 02:00 "Re: libtiff 4 API/ABI stability?", by Adam Goode
2010.06.18 13:32 "Re: libtiff 4 API/ABI stability?", by Edward Lam
2010.06.18 13:54 "Re: libtiff 4 API/ABI stability?", by Olivier Paquet
2010.06.18 02:36 "Re: libtiff 4 API/ABI stability?", by Bob Friesenhahn
2010.06.17 20:14 "Re: libtiff 4 API/ABI stability?", by Tom Lane
2010.06.17 20:35 "Re: libtiff 4 API/ABI stability?", by Bob Friesenhahn
2010.06.18 00:31 "Re: libtiff 4 API/ABI stability?", by Adam Goode

2010.06.17 17:15 "Re: libtiff 4 API/ABI stability?", by Adam Goode

On 06/17/2010 12:55 PM, Bob Friesenhahn wrote:
> On Thu, 17 Jun 2010, Adam Goode wrote:
>>
>> Yeah, getting rid of globals is a great thing to do. I started to look
>> at this some months ago: which globals are you interested in
>> eliminating? I had an idea for introducing new API calls that don't use
>> various globals so that new code could be safe, while old code could
>> still work as before.
> 
> There may be more, but the ones I noticed are related to the
> error/warning handlers.   These handlers are not thread safe.
> 
> There are also some non-const static variables used in the library.
> 
> It would be good to decide if libtiff should be thread safe.  If so,
> everything needs to be naturally re-entrant, or support for locks needs
> to be added in a few places.
> 

Yes! I would definitely love libtiff to be thread safe. The way I see
it, there are 3 levels of thread safety:

 1. libtiff API (but not TIFF structures) is usable from multiple
    threads at once.

 2. TIFF structures open for reading are usable from multiple
    threads at once.

 3. TIFF structures open for writing are usable from multiple
    threads at once.


#3 seems too hard and not worth the trouble. #1 is definitely important
and should be done. #2 would be nice, would take more work, is doable,
but is not urgent.

I say we aim for #1. This is important, not just for multiple threads,
but for multiple unrelated functions accessing libtiff from the same
memory space. In my library that uses libtiff (OpenSlide), I have to
avoid setting the error/warning callbacks in case the application has
changed them. I would like to be able to set these in my code without
interfering with the application's intent.

Also, for globals, there is also codec registration.

See my old mail for my idea:
http://www.asmail.be/msg0054681986.html



Adam