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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
