Mailing-List: contact batik-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: batik-dev@xml.apache.org
From: Thomas E Deweese <thomas.deweese@kodak.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15474.18276.937848.707595@gargle.gargle.HOWL>
Date: Tue, 19 Feb 2002 07:39:00 -0500
To: batik-dev@xml.apache.org
Subject: Re: static/threading problem with SVGFontUtilities
In-Reply-To: <3C7222EC.7DEA471E@sun.com>
References: <3C7222EC.7DEA471E@sun.com>

>>>>> "VH" == Vincent Hardy <vincent.hardy@sun.com> writes:

VH> Keiron, I have entered a Bug in Bugzilla so that we can address
VH> the problem you reported:

VH> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=6536

VH> The memory leak is a real concern.  

VH> The multi-thread problem is also a concern, but note that Batik is
VH> usually not thread safe (e.g., the SVG generator is not) in the
VH> sense that a single instance of a given class cannot be share
VH> (usually) among threads and work properly (at least, there is no
VH> guarantee it will). 

    
    Just a clarification. The problem is that loading/rendering
multiple SVG documents in different threads causes the problem.  I
think we agree that multiple threads operating on the same document is
allowed to cause problems, but I had we not agreed that it should be
"as if" all Batik data is within the scope of a single Document (i.e.
anything that is shared between documents needs to be multi-thread
safe, such as this font cache or my tile rendering cache).

VH> There are points of synchronization where multiple threads are
VH> used but not everything is thread safe.

VH> We'll look into fixing both the static reference and the
VH> multi-tread issue.

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org