[prev in list] [next in list] [prev in thread] [next in thread] 

List:       xerces-c-dev
Subject:    Re: Thread Safety Requirements on Xerces Transcoders?
From:       James Berry <james () jberry ! us>
Date:       2004-02-27 14:21:38
Message-ID: 413791D2-6930-11D8-B171-000393B2AC1A () jberry ! us
[Download RAW message or body]


On Feb 27, 2004, at 4:03 AM, Jeroen N. Witmond wrote:

>> Yes, I always assumed this (and usually, the LCP transcoder is just a
>> wrapper for some OS-specific API, with no fields defined in the class
>> definition).
>
> Yes, but this is based on the assumption that the implementation of the
> OS-specific API is re-entrant. And in Xerces. I have reason to doubt 
> that
> this assumption is sound.
>
> For instance, a number of files in directory
> xerces_c/src/xercesc/util/Transcoders/ refer to wcstombs(). On my RH9
> system, the man page for wcstombs contains the following NOTE: "The
> function  wcsrtombs  provides  a thread safe interface to the same
> functionality". According to the man pages, the difference between 
> these
> functions is that wcsrtombs is passed an additional argument "mbstate_t
> *ps", with the following comments: "In both of the above cases, if ps 
> is a
> NULL pointer, a static anonymous state only known to the wcsrtombs
> function is used instead. Passing NULL as ps is not multi-thread 
> safe.".
> My guess is that passing NULL for ps is what wcstombs (without the 'r')
> does, making it non-reentrant.

Good point, and a good question for maintainers of the various 
transcoders, of which I am one (Mac).

I only recently stumbled onto the fact that the LCP transcoder seems to 
require re-entrancy, and am considering adding a mutex to it in the Mac 
implementation. The Mac implementation very specifically calls into 
objects that maintain state, and therefore are not reentrant.

I would like to ask other committers (and users) to review the 
reentrancy of their LCP transcoders, and/or the underlying routines 
they call. We should probably make specific the requirement that they 
are to be reentrant, or else change the global usage pattern in 
XMLString and DOMString.

James.


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

[prev in list] [next in list] [prev in thread] [next in thread]