Return-Path: <awaresystems.be+caf_=filtered=awaresystems.be@gmail.com>
Delivered-To: filtered@awaresystems.be
Received: from mx5.public.one.com ([10.246.18.25])
	by mail6.local.one.com (Dovecot) with LMTP id tIgpDDVOzFjcSQEAsyOMew
	for <filtered@awaresystems.be>; Fri, 17 Mar 2017 21:03:27 +0000
X-HalOne-ID: 295d6fcb-0b55-11e7-bafc-b82a72d82f61
Received: from mail-ot0-f176.google.com (unknown [74.125.82.176])
	by mx5.public.one.com (Halon) with ESMTPS
	id 295d6fcb-0b55-11e7-bafc-b82a72d82f61;
	Fri, 17 Mar 2017 21:03:26 +0000 (UTC)
Received: by mail-ot0-f176.google.com with SMTP id a12so34134384ota.0
        for <filtered@awaresystems.be>; Fri, 17 Mar 2017 14:03:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20161025;
        h=x-original-authentication-results:x-gm-message-state:delivered-to
         :mime-version:date:from:to:in-reply-to:references:message-id
         :user-agent:subject:precedence:list-id:list-unsubscribe:list-archive
         :list-post:list-help:list-subscribe:content-transfer-encoding:sender
         :errors-to;
        bh=kw9hqQTshZChTI5LFVm5Y2BVJPBAOhCCYPYkxKoy3j0=;
        b=ojHixt1r9hs5OsszkX5BjeZr2qxw9V6WdOaxyZLgVZ/KHlo5mUW6NFiVcXg0AW6F4v
         N/rme7Pap+LluRtXl8i6+jTv48K5B/h30UB0m8J7O62Ni8GPJsV8oHb4hpe1p6gqfgRm
         6A3l2ONqQStdKnda83Ci47m8lqHzGfR19afoNcATPQz7A+3Hs2mn+d87UiMbcV6VpgKg
         jhmcqidBTZdMST1iACulazoj6ZCJ/AA7kBLPUpjJuYwA3UGv3Gj0hI/xF8ndsB7p3d5+
         2AJ3UpWh1st+w21LzvXdbrA58jzVIFDGcz/MgDdDdUouyYBR7zP/0bx1YkFBP1YABD9B
         DlDQ==
X-Original-Authentication-Results: mx.google.com;       spf=neutral (google.com: 94.23.4.142 is neither permitted nor denied by best guess record for domain of tiff-bounces@lists.maptools.org) smtp.mailfrom=tiff-bounces@lists.maptools.org
X-Gm-Message-State: AFeK/H22EJ5737HEmmveBpis/TYLTwc9mp1tKDl9lzZ021z13LMuvwV3iEM0O/+uu7KaIyTOfTP6Yd5eBdHyVjnD4Pob/Tw=
X-Received: by 10.157.11.229 with SMTP id 92mr8280390oth.85.1489784604842;
        Fri, 17 Mar 2017 14:03:24 -0700 (PDT)
X-Forwarded-To: filtered@awaresystems.be
X-Forwarded-For: awaresystems.be@gmail.com filtered@awaresystems.be
Delivered-To: awaresystems.be@gmail.com
Received: by 10.202.195.2 with SMTP id t2csp473936oif;
        Fri, 17 Mar 2017 14:03:23 -0700 (PDT)
X-Received: by 10.223.135.215 with SMTP id c23mr14469085wrc.135.1489784603753;
        Fri, 17 Mar 2017 14:03:23 -0700 (PDT)
Return-Path: <tiff-bounces@lists.maptools.org>
Received: from lists.maptools.org (ks365428.kimsufi.com. [94.23.4.142])
        by mx.google.com with ESMTP id x96si12572153wrb.290.2017.03.17.14.03.22;
        Fri, 17 Mar 2017 14:03:23 -0700 (PDT)
Received-SPF: neutral (google.com: 94.23.4.142 is neither permitted nor denied by best guess record for domain of tiff-bounces@lists.maptools.org) client-ip=94.23.4.142;
Authentication-Results: mx.google.com;
       spf=neutral (google.com: 94.23.4.142 is neither permitted nor denied by best guess record for domain of tiff-bounces@lists.maptools.org) smtp.mailfrom=tiff-bounces@lists.maptools.org
Received: from [10.1.0.241] (localhost.localdomain [127.0.0.1])
	by lists.maptools.org (Postfix) with ESMTP id AB85935C062;
	Fri, 17 Mar 2017 16:02:25 -0500 (EST)
Received: from a-painless.mh.aa.net.uk (a-painless.mh.aa.net.uk [81.187.30.51])
	by lists.maptools.org (Postfix) with ESMTPS id 4CBE535C060
	for <tiff@lists.maptools.org>; Fri, 17 Mar 2017 16:02:12 -0500 (EST)
Received: from b-webmail.mh.aa.net.uk ([2001:8b0:0:30::77]
	helo=webmail.aa.net.uk) by a-painless.mh.aa.net.uk with esmtpsa
	(TLS1.0:ECDHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.84_2)
	(envelope-from <rleigh@codelibre.net>) id 1coz0m-0007mW-6K
	for tiff@lists.maptools.org; Fri, 17 Mar 2017 21:02:12 +0000
Received: from [134.36.162.126] by webmail.aa.net.uk
	with HTTP (HTTP/1.1 POST); Fri, 17 Mar 2017 21:02:09 +0000
MIME-Version: 1.0
Date: Fri, 17 Mar 2017 21:02:09 +0000
From: rleigh@codelibre.net
To: tiff@lists.maptools.org
In-Reply-To: <alpine.GSO.2.20.1703171154040.4525@scrappy.simplesystems.org>
References: <CAHcSuBpB46=uPKCS48LuFCqbZ1GeQau6_f8Bbbj5fs6LbJdE+Q@mail.gmail.com>
	<alpine.GSO.2.20.1703170947500.4525@scrappy.simplesystems.org>
	<CAHcSuBqZQh4kJH_R_9LEkpnjRm=s-CmOE_vcoyRF6fxgwt1B8A@mail.gmail.com>
	<alpine.GSO.2.20.1703171154040.4525@scrappy.simplesystems.org>
Message-ID: <18b5b63b7b889c5c3c9f51af1b2651c4@codelibre.net>
X-Sender: rleigh@codelibre.net
User-Agent: Roundcube Webmail/1.1.5
Subject: Re: [Tiff] TIFFSetErrorHandler vs TIFFSetErrorHandlerExt
X-BeenThere: tiff@lists.maptools.org
X-Mailman-Version: 2.1.9
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>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org

On 2017-03-17 17:02, Bob Friesenhahn wrote:
> On Fri, 17 Mar 2017, Dinesh Iyer wrote:
> 
>> Thanks Bob.
>> 
>> If I understand you correctly, I cannot have multiple threads each 
>> with its
>> own handler throwing errors/warnings. i need to ensure that only one 
>> thread
>> does the error handling, am I correct?
> 
> You can only register one error handling function at a time.  The
> function will be called under the same context as the thread which
> encountered the problem.  Knowing that it is called under the same
> execution context can be very useful.
> 
>> As a follow up, do i have to set the client_data field with a pointer 
>> to my
>> class such that it is accessible in the callbacks?
> 
> The client_data is for you.  If you use TIFFClientOpen() then it is
> provided so that you can use it has a handle for I/O or other
> purposes (e.g. also for errors).
> 
> In GraphicsMagick I use TIFFSetErrorHandler()/TIFFSetWarningHandler()
> and I use thread-specific data (POSIX or Windows) to reconcile between
> the error callback data and what the thread was working on.  I don't
> use client_data for that purpose.  This approach works if there is
> just one thread which ever does libtiff operations for a given handle.
> 
> The reason for the approach in GraphicsMagick is that the
> implementation pre-dates the addition of TIFFSetErrorHandlerExt() and
> it also works for older libtiff.

Could I suggest a perhaps controversial but useful solution for handling 
errors, which might be worth your consideration.

If the libtiff core were to use a C++ TIFF class reporting errors via 
exceptions, it would be possible for this to be wrapped by the existing 
C API calling the C++ code in a try/catch block and reporting any thrown 
errors via the handlers.  Or direct use by C++ code without any of that 
overhead--it could use the C++ API directly with exceptions.  This would 
permit completely thread-safe use from C++, and it would also permit 
multiple C error handling strategies--either with the global handler as 
now, a per-TIFF handler or something completely different.  The C API 
could simply be a thin wrapper around the C++ core, and remain 100% 
backward compatible while also allowing direct use from C++ without 
wrapping the C code.

In the OME project I currently work on, we already have a fairly complex 
C++ wrapper around the C API.  It works, but due to the need to 
synchronise for the context-specific error handler, it's much more 
inefficient and complex than it would need to be were it native.  If 
using a C++ core would be something worth considering, it's likely I 
could dedicate some paid time to working on it, since it would replace a 
whole lot of wrapper code we already have to maintain.


Regards,
Roger

_______________________________________________
Tiff mailing list: Tiff@lists.maptools.org
http://lists.maptools.org/mailman/listinfo/tiff
http://www.remotesensing.org/libtiff/
