Return-Path: <tiff-bounces@lists.maptools.org>
Received: from inas017.isp.belgacom.be (localhost [127.0.0.1])
        by inav020.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-AV-3.00) with ESMTP id l2NGDvT8016044
        for <joris.at.lebbeke@skynet.be>; Fri, 23 Mar 2007 17:13:57 +0100
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from inmx024.isp.belgacom.be (inmx024.isp.belgacom.be [195.238.6.143])
        by inas017.isp.belgacom.be (8.12.11.20060308/8.12.11/Skynet-IN-AS-2.03) with ESMTP id l2NGDqNm002235
        for <joris.at.lebbeke@skynet.be>; Fri, 23 Mar 2007 17:13:54 +0100
        (envelope-from <tiff-bounces@lists.maptools.org>)
Received: from mailgate101.isp.belgacom.be (mailgate101.isp.belgacom.be [195.238.6.82])
	by inmx024.isp.belgacom.be (Postfix) with ESMTP id 968093AC085
	for <joris.at.lebbeke@skynet.be>; Fri, 23 Mar 2007 17:13:54 +0100 (CET)
Received: from r153.dmsolutions.ca (HELO duke.maptools.org) ([209.217.116.153])
  by in.mx.skynet.be with ESMTP; 23 Mar 2007 16:58:30 +0100
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 l2NFnHj8015596;
	Fri, 23 Mar 2007 10:50:08 -0500
Received: from mail.fusionsystems.com (fusionsystems.com [64.122.195.140])
	by duke.maptools.org (8.12.11/8.12.10) with ESMTP id l2NFnFjP015593
	for <tiff@lists.maptools.org>; Fri, 23 Mar 2007 10:49:16 -0500
Received: from [192.168.1.189] ([192.168.1.189])
	by mail.fusionsystems.com (8.13.1/8.13.1) with ESMTP id l2NGiRSD024628
	for <tiff@lists.maptools.org>; Fri, 23 Mar 2007 08:44:27 -0800
Mime-Version: 1.0 (Apple Message framework v752.3)
X-Priority: 3
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id: <AEC87118-9FA3-42F7-A167-00301F25F0AC@fusionsystems.com>
Content-Transfer-Encoding: 7bit
From: Tim Tomassi <timt@fusionsystems.com>
Date: Fri, 23 Mar 2007 08:49:13 -0700
To: tiff@lists.maptools.org
X-Mailer: Apple Mail (2.752.3)
X-Virus-Scanned: ClamAV 0.85.1/2912/Fri Mar 23 03:07:37 2007 on
	web.fusionsystems.com
X-Virus-Status: Clean
X-Spam-Status: No, score=-2.8 required=5.0 tests=ALL_TRUSTED autolearn=failed 
	version=3.0.4
X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on 
	web.fusionsystems.com
Subject: [Tiff] Any known problems with using libtiff G4 compression in a
	multithreaded application?
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.0000222e
X-MSP-STORE: Fri, 23 Mar 2007 17:13:59 +0100
Status:   

Hello,

I am using libtiff-3.7.2 as a compression engine within an  
application that I am developing.  I use TIFFClientOpen() so that I  
can receive data buffers from both the LZW and the G4 compression  
engines into my TIFFWriteProc().

I am in the process of expanding my application so that it works  
efficiently on SMP hardware.  To do this, I launch a set of of worker  
threads and open an equivalent number of TIFF files with  
TIFFClientOpen().  The threads each deliver uncompressed data to  
libtiff in parallel, with each separate TIFF file getting a different  
band of data to compress.  Within my TIFFWriteProc(), I serialize the  
strips of compressed data that I receive from libtiff and write it  
out to the actual destination file.

I am encountering intermittent data corruption of individual strips  
when I execute my application with more than one thread.  However,  
this corruption only occurs when the G4 compression feature of  
libtiff is used.  LZW compression never experiences any corruption,  
regardless of the number of threads I run.  This leads me to suspect  
that the G4 compression engine might have some type of problem if  
more than one band of data is being compressed simultaneously within  
the library.  I have scanned tif_fax3.c, looking for obvious examples  
of non-thread-safe code, but I don't have a lot of experience with  
the internals of libtiff, so I easily could have missed something.

Are there any data structures within libtiff that might preclude it  
from being used simultaneously with more than one open TIFF file?   
Are there other areas where libtiff might not be multithread safe,  
and could cause errors in the G4 compression if the engine is used to  
compress multiple buffers simultaneously?

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