From owner-tiff@olympiakos.com  Thu Mar 16 14:30:25 2000
Received: (from uucp@localhost)
	by smtp02.oce.nl (8.9.3/8.9.3) id OAA00346
	for rvdt@smtp02; Thu, 16 Mar 2000 14:30:25 +0100 (MET)
>Received: from gate7.olympiakos.com ([207.176.88.85])
	by oce.nl (8.9.0/8.9.0) with ESMTP id OAA10730;
	Thu, 16 Mar 2000 14:27:55 +0100 (MET)
Received: from localhost (daemon@localhost)
	by gate7.olympiakos.com (8.9.3/8.9.3) with SMTP id IAA25727;
	Thu, 16 Mar 2000 08:23:22 -0500
Received: by gate7.olympiakos.com (bulk_mailer v1.9); Thu, 16 Mar 2000 08:19:09 -0500
Received: (from majordom@localhost)
	by gate7.olympiakos.com (8.9.3/8.9.3) id IAA25686
	for tiff-outgoing; Thu, 16 Mar 2000 08:19:08 -0500
X-Authentication-Warning: gate7.olympiakos.com: majordom set sender to owner-tiff@olympiakos.com using -f
Received: from as121.tel.hr (as121.tel.hr [205.219.255.37])
	by gate7.olympiakos.com (8.9.3/8.9.3) with ESMTP id IAA25683
	for <tiff@olympiakos.com>; Thu, 16 Mar 2000 08:18:27 -0500
Received: from STORMTROOPER (ad12-m5.tel.hr [195.29.235.5])
	by as121.tel.hr (0.0.0/0.0.0) with SMTP id OAA60203
	for <tiff@olympiakos.com>; Thu, 16 Mar 2000 14:18:03 +0100 (MET)
Message-ID: <003301bf8f4a$62f860e0$5101a8c0@STORMTROOPER>
From: "Ivo" <ivo.penzar@infolink-software.com>
Cc: <tiff@olympiakos.com>
References: <38CFCC1B.B75FE060@med-web.com> <38CFD836.2B9@srz-berlin.de>
Subject: -D_REENTRANT for libtiff and jpeg?
Date: Thu, 16 Mar 2000 14:20:11 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2919.6700
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700
Sender: owner-tiff@olympiakos.com
Content-Type: text/plain;
	charset="iso-8859-1"

For our cross-platform project on 9x/NT/2K, Linux and Sun (should also work
on others, we didn't test yet) we use the libtiff and jpeg (The JPEG
Independent Group) open source libraries. Thanks to their authors and to
this group.

It is our Java image viewer (and another, Visual C++ based) which uses our
"native code" (C++) imaging dynamic/shared library to read/write/manipulate
TIFF, JPEG, BMP, GIF, and CALS images. This library then, for the low-level
TIFF and JPEG read/write operations, calls to the libtiff and jpeg
libraries...

That our topmost library successfully handles the multithreading and locking
of individual image objects. I.e., two threads could never access the same
image object (and hence, the same tiffinfo or jpeg_decompress_struct), but
two different threads could probably work concurrently on two different tiff
or jpeg images.

My basic CLockable class (to provide a platform-independent interface and to
hide its platform-dependent implementation) is actually built on top of
WIN32 mutexes (NT), POSIX threads (Linux, Unix) and native threads
(Solaris). Thus we build the libtiff/libjpeg as Multithreading dll on
Windows, i.e., with _REENTRANT macro defined on Solaris.

So far, so good (almost). Nevertheless, I am still not complitely sure if
there could be some non-reentrant functions or static variables deep into
the libtiff or jpeg libraries?

Does anybody else have some good or bad expirience with the libtiff  and
jpeg libraries in such a multithreading environments? Or knows of some
particular functions which are not reentrant. Or has a proven knowledge
(based on the source-code inspection) that everything those libraries do for
reading/writing is properly localized into the corresponding tiffinfo and
jpeg_decompress_struct/jpeg_compress_struct structures.

Thanks for your opinions.
Ivo




