Return-Path: <tiff-bounces@lists.maptools.org>
X-Original-To: info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-r.b-one.net (mx-r.one.com [91.198.169.249])
	by mail9.b-one.net (Postfix) with ESMTP id 47A7E40024F
	for <info@awaresystems.be>; Fri, 18 Jun 2010 02:54:12 +0200 (CEST)
Received: by mx-r.b-one.net (Postfix, from userid 106)
	id 2E7E73A389A6; Fri, 18 Jun 2010 02:54:12 +0200 (CEST)
X-Virus-Scanned: by one.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "MIME-Version"
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4
Received: from lists.maptools.org (lists.maptools.org [65.39.174.144]) by
 mx-r.b-one.net (Postfix) with ESMTP id C07733A389A6 for
 <info@awaresystems.be>; Fri, 18 Jun 2010 02:54:10 +0200 (CEST)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by
 lists.maptools.org (Postfix) with ESMTP id 74C2C1D18E509; Thu, 17 Jun 2010
 19:53:37 -0500 (EST)
Received: from out1.smtp.messagingengine.com (out1.smtp.messagingengine.com
 [66.111.4.25]) by lists.maptools.org (Postfix) with ESMTPS id CB5F81D0E52B6
 for <tiff@lists.maptools.org>; Thu, 17 Jun 2010 19:31:40 -0500 (EST)
Received: from compute1.internal (compute1.internal [10.202.2.41]) by
 gateway1.messagingengine.com (Postfix) with ESMTP id 55FB9FAADA; Thu, 17 Jun
 2010 20:31:40 -0400 (EDT)
Received: from heartbeat1.messagingengine.com ([10.202.2.160]) by
 compute1.internal (MEProxy); Thu, 17 Jun 2010 20:31:40 -0400
X-Sasl-enc: fX9Q5ImZBsIUFzMT86m6WTtSV2egvcWwaj7Yq8yrviTc 1276821100
Received: from [192.168.1.125] (c-71-236-65-235.hsd1.pa.comcast.net
 [71.236.65.235]) by mail.messagingengine.com (Postfix) with ESMTPSA id
 D35504D0341; Thu, 17 Jun 2010 20:31:39 -0400 (EDT)
Message-ID: <4C1ABE68.30107@spicenitz.org>
Date: Thu, 17 Jun 2010 20:31:36 -0400
From: Adam Goode <adam@spicenitz.org>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.9)
 Gecko/20100430 Fedora/3.0.4-3.fc13 Thunderbird/3.0.4
MIME-Version: 1.0
To: Bob Friesenhahn <bfriesen@simple.dallas.tx.us>
References: <4C1A41A5.4070409@spicenitz.org>
 <alpine.GSO.2.01.1006171125140.12887@freddy.simplesystems.org>
 <4C1A4E8A.1060904@spicenitz.org>
 <alpine.GSO.2.01.1006171150230.12887@freddy.simplesystems.org>
 <4C1A5840.5000300@spicenitz.org>
 <AANLkTing-04iFpEr0k9-6DaA7DQFTRrFjOjdQ5g2RXM0@mail.gmail.com>
 <4C1A64CF.2060607@spicenitz.org>
 <alpine.GSO.2.01.1006171326540.12887@freddy.simplesystems.org>
In-Reply-To: <alpine.GSO.2.01.1006171326540.12887@freddy.simplesystems.org>
X-Enigmail-Version: 1.0.1
Cc: Tiff List <tiff@lists.maptools.org>
Subject: Re: [Tiff] libtiff 4 API/ABI stability?
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: multipart/mixed; boundary="===============2100389451=="
Mime-version: 1.0
Sender: tiff-bounces@lists.maptools.org
Errors-To: tiff-bounces@lists.maptools.org

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--===============2100389451==
Content-Type: multipart/signed; micalg=pgp-sha1;
 protocol="application/pgp-signature";
 boundary="------------enigEABCB92974F7FE73AA83FBB8"

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigEABCB92974F7FE73AA83FBB8
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 06/17/2010 02:47 PM, Bob Friesenhahn wrote:
> On Thu, 17 Jun 2010, Adam Goode wrote:
>>
>> Yeah, it will work ok in 99% of cases. It won't work if one library
>> needs to register a codec that changes the behavior of another library=
,
>> for example. Not so much an issue if you're using libtiff from an
>> application, but it is if you're writing a library that uses libtiff.
>=20
> In this case you would need to have an 'application' handle which
> contains all application specific references, where a single "program"
> could have multiple handles.  Multiple users of libtiff in a single
> application becomes more common as applications become huge and use man=
y
> other libraries (some apps seem to use over 70 libraries now).
>=20

Yes, that sounds about right. Though I don't think an application handle
is strictly necessary, I would just pass the warning/error callbacks and
codecs directly to TIFFOpen (following the Law of Demeter). Though
putting it all together into an application handle is ok too.

> I have seen very good success from using thread specific data (TSD),
> which is supported under POSIX and Microsoft Windows, and is easily
> emulated in a non-threaded build.  TSD can be much more efficient than
> using shared data with locking if the algorithm can get by with
> different data per thread.  There are also TSD compiler extensions for
> GCC and MSVC but I would not want to use something non-portable like th=
at.
>=20

Yeah, I definitely think locks are not the way to go. And I don't think
they are necessary for implementing the kind thread safety we are
looking for here. You just need to allocate a bit more on the heap and
pass things in. libjpeg definitely does this right.


Adam


--------------enigEABCB92974F7FE73AA83FBB8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAkwavmoACgkQlenB4PQRJawc7gCfSgcgHQFbv2nUBd6PdFBQRX5g
AWgAoIQNJ8naILGU/zffHy8uRcjCNnnV
=R+GR
-----END PGP SIGNATURE-----

--------------enigEABCB92974F7FE73AA83FBB8--

--===============2100389451==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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