Return-Path: <tiff-bounces@lists.maptools.org>
X-Original-To: info@awaresystems.be
Delivered-To: info@awaresystems.be
Received: from mx-l.b-one.net (mx-l.one.com [91.198.169.59])
	by mail9.b-one.net (Postfix) with ESMTP id 88F5F400125
	for <info@awaresystems.be>; Tue, 17 Feb 2009 23:17:10 +0100 (CET)
X-Virus-Scanned: by one.com
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=0 required=6 tests=[none]
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.4
Received: from lists.maptools.org (lists.maptools.org [65.39.174.144])
	by mx-l.b-one.net (Postfix) with ESMTP id D82291D18B2C
	for <info@awaresystems.be>; Tue, 17 Feb 2009 23:17:09 +0100 (CET)
Received: from localhost.localdomain (localhost.localdomain [127.0.0.1])
	by lists.maptools.org (Postfix) with ESMTP id E18DB1D18FB1D;
	Tue, 17 Feb 2009 17:16:38 -0500 (EST)
Received: from csmtp3.b-one.net (csmtp3.one.com [195.47.247.213])
	by lists.maptools.org (Postfix) with ESMTP id 495631D18FB4D
	for <tiff@lists.maptools.org>; Tue, 17 Feb 2009 16:36:45 -0500 (EST)
Received: from awarec74cb3e1c (78-22-4-241.access.telenet.be [78.22.4.241])
	by csmtp3.b-one.net (Postfix) with ESMTP id 473E2240F402;
	Tue, 17 Feb 2009 22:36:45 +0100 (CET)
Message-ID: <BBB2D1500533442097B4771133655294@awarec74cb3e1c>
From: "Joris Van Damme \(AWare Systems\)" <info@awaresystems.be>
To: <pwatkins@crawfordtech.com>, "TIFF mailing list" <tiff@lists.maptools.org>
References: <20090217170424.A71EEC2EE05@mx-e.b-one.net>
Date: Tue, 17 Feb 2009 22:36:42 +0100
MIME-Version: 1.0
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.5512
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579
Subject: Re: [Tiff] Accessing tif->tif_clientdata within my own error
	andwarning functions
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

Philip,


> Next question - It looks like the warning and error handling is not thread
> safe. I guess that I would have to add function pointers to TIFF?

"Thread safe" is such an over-simplification that I find it's actually a
catch phrase without meaning when it does not come accompanied by an
elaborate description of the threading situation you designed.

If only one thread is working on a particular TIFF context, then things
should be fine. There is no thread context switching or anything under the
LibTiff hood, so the warnings and errors that trigger calls to your handlers
should do so inside the thread context and all remains safe. I'd go as far
as using the words thread-blind to describe LibTiff, if only that term
existed, and such is a good starting point for thread-safe usage, as it is
for continued thread-blind usage and single-thread usage also.

If by "thread safe" you mean to say that you want things like having worker
threads on the one hand calling LibTiff, and having the warning handlers do
UI thread specific stuff like putting up a windows, then sure, you need
synchronisation mechanisms exactly like you do with the decoders output when
you decide to render it inside a UI. Probably appending rendering and
warning output to protected objects shared with the UI thread, and posting
messages to the UI thread signalling that data appending event, is one of
the easiest and most common schemes.

If by "not thread safe" you mean to say that there's a chance that the
context pointed to by the tif->tif_clientdata is deleted/freed/invalidated
before all work on the TIFF* object is done, thereby rendering it possible
that the tif->tif_clientdata is an invalid pointer at the time your handler
is called, then I'd say this is defenetly a design you should avoid. I
wouldn't refer to the objects used as "not thread safe" in this case, but to
the design as buggy. Use usage counters when you must, think of the TIFF* as
strictly owned by the context pointed to by tif->tif_clientdata or whatever,
but keep the context alive and the pointer to it unchanging as long as
there's a valid TIFF* logically 'inside' it.

But there's thirteen dozen other things you could mean with "thread safe".
You'll have to elaborate if your question is answered already.


Best regards,

Joris

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