AWARE SYSTEMS
TIFF and LibTiff Mail List Archive

Thread

2007.08.09 12:07 "[Tiff] Error handling & threading", by John Aldridge
2007.08.09 14:30 "Re: [Tiff] Error handling & threading", by Frank Warmerdam
2007.08.10 10:50 "Re: [Tiff] Error handling & threading", by Joris Van Damme
2007.08.10 12:02 "Re: [Tiff] Error handling & threading", by John Aldridge

2007.08.10 12:02 "Re: [Tiff] Error handling & threading", by John Aldridge

In a multi-threaded application, it can be a nuisance that the handlers set by TIFFSetErrorHandler[Ext] & TIFFSetWarningHandler[Ext] are static variables.

Would there be any sympathy for adding a pair of such handler function pointers to the TIFF structure?

  :

If you interface with the extended version, you get your clientdata pointer passed to your handler. A clientdata pointer can point to anything, and though it might require a bit of a detour, it should normally be possible to have it point to whatever data you need to make your handler decide how to pass it on to, e.g. per-TIFF structure error policy handlers. Thus, in essence, you already have this functionality, though it may require you to approach your clientdata more indirectly (i.e. if it currently is, say, a file handle, you'll need to make it point to a structure that holds file handle and error policy both, instead).

Understood, I think, though this is quite a lot of work! To get back the equivalent functionality of (e.g.) TIFFOpen I'd need to write variant versions of all of

   TIFFOpen
   TIFFFdOpen

   _tiffReadProc
   _tiffWriteProc
   _tiffSeekProc
   _tiffCloseProc
   _tiffSizeProc
   _tiffMapProc
   _tiffUnmapProc

though the last 7 can be trivial wrappers. I guess that's the "bit of a detour" you referred to!

--
Thanks,

John