Received: from mailgate003.isp.belgacom.be (mailgate003.isp.belgacom.be [195.238.6.88])
	by maildelivery003.isp.belgacom.be (Postfix) with ESMTP id 0AD681D8006
	for <joris.at.lebbeke@skynet.be>; Fri, 10 Aug 2007 13:01:43 +0200 (CEST)
Received: from r153.dmsolutions.ca (HELO duke.maptools.org) ([209.217.116.153])
  by in.mx.skynet.be with ESMTP; 10 Aug 2007 13:01:43 +0200
Received: from duke.maptools.org (duke.maptools.org [127.0.0.1])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id l7AAoYNr014107;
	Fri, 10 Aug 2007 06:51:32 -0400
Received: from mailrelay008.isp.belgacom.be (mailrelay008.isp.belgacom.be
	[195.238.6.174])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id l7AAo7bM014100
	for <tiff@lists.maptools.org>; Fri, 10 Aug 2007 06:50:08 -0400
Received: from 112.134-246-81.adsl-dyn.isp.belgacom.be (HELO AWareCore2Duo)
	([81.246.134.112])
	by mailrelay008.isp.belgacom.be with SMTP; 10 Aug 2007 12:50:06 +0200
Message-ID: <00b201c7db3c$3508fa50$0201a8c0@AWareCore2Duo>
From: "Joris" <joris.at.lebbeke@skynet.be>
To: "John Aldridge" <john.aldridge@informatix.co.uk>,
        "TIFF mailing list" <tiff@lists.maptools.org>
References: <46BB0376.60005@informatix.co.uk>
Subject: Re: [Tiff] Error handling & threading
Date: Fri, 10 Aug 2007 12:50:01 +0200
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3138
Cc: 
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.4
Precedence: list
List-Id: TIFF and libtiff discussion <tiff.lists.maptools.org>
List-Unsubscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=unsubscribe>
List-Archive: <http://lists.maptools.org/mailman/private/tiff>
List-Post: <mailto:tiff@lists.maptools.org>
List-Help: <mailto:tiff-request@lists.maptools.org?subject=help>
List-Subscribe: <http://lists.maptools.org/mailman/listinfo/tiff>,
	<mailto:tiff-request@lists.maptools.org?subject=subscribe>
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org
X-UIDL: 000000000023ceae.00002705
X-MSP-STORE: Fri, 10 Aug 2007 13:01:43 +0200
Status:   

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
_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
