Re: [xslt] "libxslt with thread-enabled libxml2?"

[Daniel Veillard <veillard redhat com>]

On Fri, Apr 11, 2003 at 12:50:01PM -0700, Peter Jones wrote:
> Hey, remember back when Daniel Veillard said:
> > I expect to switch libxml2 compilation to be thread aware on Linux 
> 
> Maybe I am missing something here, but why does libxslt need to be
> "thread aware"?
> 
> I should point out my definition of thread aware, vs. thread safe.
> 
> Thread aware is when the library detects that it is being used in a
> multithreaded application and uses things like mutexes to protect parts
> of the library that are not thread safe.

  Actually libxml2 XPath already have some thread awareness, but it doesn't
need to be changed.

> Now, maybe we are talking about some of the libxslt callbacks. If I

  Not specifically ...

> wanted to write an XPath extension function I would need to give libxslt
> a callback function.
> If libxslt was tread aware, it would lock some mutex before it called my
> callback (maybe). If it was thread safe, it would allow me to use a
> context pointer that gets passed to the callback, and the callback would
> decide whether or not a mutex needs to be locked.

  I would defer thtis to the application level.

> It is definitely a matter of opinion and preference, but I don't think
> libxslt should be thread aware, just thread safe. The bonus of thread
> safety, is it usually yields a better design, e.g. no global variables.

  There are global variables in libxslt. But they should not be a problem
in practice.
  My initial mail is just ...
  "I'm gonna make --enable-thread the default compilation switch on Linux
   and I'm asking for possible problems at the libxslt level..."
If it works, then fine :-)

Daniel

-- 
Daniel Veillard      | Red Hat Network https://rhn.redhat.com/
veillard@redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/