LibTiff Mailing List

John,

John Aldridge wrote:
> 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? I suppose we'd need to add new
> versions of the
>
>   TIFFOpen, TIFFOpenW, TIFFFdOpen, TIFFClientOpen
>
> functions which takes such function pointers as arguments and fill
> them into the returned TIFF structure. The existing open functions
> could just default them to the current TIFFErrorExt and
> TIFFWarningExt functions.
> Then all calls to TIFFErrorExt and TIFFWarningExt in the library could
> be replaced by one of
>
>    tiff->tif_errorProc (...)
>    tiff->tif_warningProc (...)
>
> These changes would allow applications to establish per-TIFF strcture
> error policy without upsetting existing code.

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

In essence, what I'm saying is, a pointer indexes the complete universe. 
This is why I'm opposed to anything that goes beyond this (like having 
multiple clientdata vars, for example), as in essence this unnatural 
shifting of responsability will always be too small for some applications 
that need to maintain even more per-TIFF stuff, unless all applications are 
willing to group what they need in a structure and have a single clientdata 
pointer point to it.

Best regards,

Joris Van Damme
info@awaresystems.be
http://www.awaresystems.be/
Download your free TIFF tag viewer for windows here:
http://www.awaresystems.be/imaging/tiff/astifftagviewer.html


AWARE [SYSTEMS]		Imaging expertise for the Delphi developer
		TIFF and LibTiff Mailing List Archive
	LibTiff Mailing List TIFF and LibTiff Mailing List Archive August 2007 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	Thread 2007.08.09 12:07 "Error handling & threading", by John Aldridge 2007.08.09 14:30 "Re: Error handling & threading", by Frank Warmerdam 2007.08.10 10:50 "Re: Error handling & threading", by Joris Van Damme 2007.08.10 12:02 "Re: Error handling & threading", by John Aldridge 2007.08.10 10:50 "Re: Error handling & threading", by Joris Van Damme John, John Aldridge wrote: > 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? I suppose we'd need to add new > versions of the > > TIFFOpen, TIFFOpenW, TIFFFdOpen, TIFFClientOpen > > functions which takes such function pointers as arguments and fill > them into the returned TIFF structure. The existing open functions > could just default them to the current TIFFErrorExt and > TIFFWarningExt functions. > Then all calls to TIFFErrorExt and TIFFWarningExt in the library could > be replaced by one of > > tiff->tif_errorProc (...) > tiff->tif_warningProc (...) > > These changes would allow applications to establish per-TIFF strcture > error policy without upsetting existing code. 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). In essence, what I'm saying is, a pointer indexes the complete universe. This is why I'm opposed to anything that goes beyond this (like having multiple clientdata vars, for example), as in essence this unnatural shifting of responsability will always be too small for some applications that need to maintain even more per-TIFF stuff, unless all applications are willing to group what they need in a structure and have a single clientdata pointer point to it. Best regards, Joris Van Damme info@awaresystems.be http://www.awaresystems.be/ Download your free TIFF tag viewer for windows here: http://www.awaresystems.be/imaging/tiff/astifftagviewer.html

LibTiff Mailing List

Thread

2007.08.10 10:50 "Re: Error handling & threading", by Joris Van Damme