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

[Daniel Veillard <veillard redhat com>]

On Fri, Apr 11, 2003 at 11:02:25PM +0200, Igor Zlatkovic wrote:
> On Fri, Apr 11, 2003 at 02:57:42PM -0400, Daniel Veillard wrote:
> >   Hum, could you be more precise if something is needed at the code level.
> > I expect to switch libxml2 compilation to be thread aware on Linux 
> > (now that some performances problems with memory allocation when compiling
> > with threads have been addressed). So if libxslt needs work I'm interested
> > of getting your advice :-)
> 
> Well, I guess libxslt will need the same protection libxml allready has.
> Imagine ten threads applying the same stylesheet on ten different
> documents. Each thread has its own vision of what, say, xsltGenericError
> or xsltMaxDepth should contain and start setting and resetting these at
> the whim of the kernel scheduler. I have never tested it, but that
> doesn't sound good to me :-)

  Well per transformation error context is simple allow to register them
at the transformation context level and if not defined cascade to the global
one. Actually it's already the case c.f. fields error and errctx in the
transformation context. Concerning xsltMaxDepth it really is a global
setting, one should not need to tune it per transformation. 
  Each thread runs it's own transformation with it own context and the
stylesheets are read-only, that works already ...

> That aside, I strongly believe that thread sync on that level should be
> left to the application code. Neither libxml nor libxslt can ever know
> what an application will do with them.

  My question was whether once needed to change something now to compile
libxslt with thread support on Windows.

> Libxml and libxslt don't need or use asynchronous processing, like I
> call some function implemented in these and do other work until I
> receive a notification about the results. As long this remains that way,
> I would leave thread sync to the applications, there is no better place
> for that.

  Yep I didn't intended to change that level.

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/