Re: [xml] Multithread behaviour on Solaris

Daniel Veillard wrote:

On Thu, Jun 07, 2001 at 10:41:20AM +0200, Fabrice DESRE - FT.BD/FTRD/DMI/GRI wrote:

 I'm using libxml/libxslt on Solaris in a multithreaded
application and found an easy to fix bug : The _REENTRANT
flag has to be specified when compiling the library to
avoid inconsistent behaviour of errno.
  Including <errno.h> with _REENTRANT defined make errno
a macro that gets the correct value when in a thread.
Otherwise you always get 0 :-(

That's not correct. If a threaded application calls into a thread-unsafe library, then
you still get a per-thread errno as long as you had defined _REENTRANT and included
<errno.h> . Make sure that your threads are not entering libxml2 in an unsafe fashion
and you should be ok.

  Hum, what should be used as the result of config.guess
for Solaris so I can add it to .
  I assume adding the _REENTRANT define won't have other side
effects and can be used in a safe way. Well actually if Gary
could confirm it's a safe thing to do in general I would feel
better adding this :-)

Multi-threading with a non-thread safe library is always problematic. I'm not sure
that this is the correct approach, since distributing libxml2 with the _REENTRANT flag
always defined will incur some slight overhead for the vast majority of applications
that aren't multi-threaded. Personally, I would like to see it as a configure option
or simply by setting CC or CFLAGS to include -D_REENTRANT (or -mt if you are using the
Workshop compiler) when you are building libxml2. Also, people would still have to
decide if they wanted Solaris or Posix semantics in their thread library and would
still have to define (or not) _POSIX_PTHREAD_SEMANTICS and/or D_POSIX_C_SOURCE=N
(where N  199506L).

I'm quoting from the Multithreaded Programming Guide here:


Compile single-threaded applications, not linked with either of the thread libraries ( or, without the -D_REENTRANT flag. This eliminates performance degradation incurred when 
macros, such
as putc(3s), are converted into reentrant function calls.

If you want more detail, take a look at:

(I think that's a public server. It has lots and lots of documentation and is useful
for all things Sun)

 I also noticed that trio.c define errno as an extern int,
which is not the correct way.

  Hum, maybe Bjorn can have a look at this, it seems trio
includes errno.h so maybe this definition is done only in a
fallback case.

Removing the extern statement would be correct on Solaris; I think it should also be
correct on other Unixen but I defer to Bjorn.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]