Re: [xslt] Few questions

[Carlo Contavalli <ccontavalli libero it>]

On Thu, Sep 11, 2003 at 05:57:12PM -0400, Daniel Veillard wrote:
> >     	xsltEvalTemplateString(...)
> > 
> >     is this correct?
>    Maybe maybe not, I don't undertsnad fully what you're looking for
> and I don't remember that function in particular.
> >	[ ...]
> >     the error (something smarter than removing the fallback node 
> >     from the tree)?
> 
>    No idea. Use the source, put a breakpoint in your routine and see what's
> happen !
I already have a clear idea of what's going on. I just don't know if it's
my fault (missuse of a function) or there's something else. I'll try to
be more clear. Let's say I have a xsl like this:

<xsl:stylesheet version="1.0" extension-element-prefixes="myown" ...>
[...]
<xslt:template match="fuffa">
  <myown:ext-tag name="fuffa">
    <xsl:fallback>
    foo bar
    </xsl:fallback>

    foo bar

    <xsl:value-of select="@attrib" />
  </myown:ext-tag>
  [...]

The function handling ``myown:ext-tag'' needs all the data that
would be generated by the interpretation of the underlying xslt
tags (foo bar... <xsl:value-of ...). So, the handler calls
xsltEvalTemplateString, with the children pointer as an
argument. xsltEvalTemplateString calls xsltApplyOneTemplate, that 
reads each node in the tree to produce the correct output. 
When xsltApplyOneTemplate finds the <fallback node, it looks for 
the compiled data in the _private pointer, but the fallback private 
ptr is NULL, and there comes the error.
Now, the question is, am I wrong using xsltEvalTemplateString? 
Should I use some other function? Should I do something else before
calling xsltEvalTemplateString (like removing the fallback
node?)? Is this behavior expected? 

>    Define you own entity handler, see the documentation of libxml2 in
> the "I/O Interfaces" page.
No big deal, I already took a look at that page, just wanted to know if 
it was the expected behavior or if there was a shortcut.

> >     Is this behavior expected? How can I make sure 
> >     xsltGenericError gets called only with its own context
> >     (without enabling debugging - still there in 1.0.32)?
>   No idea how you got there. Sorry you will have to debug !
:) Well, I got there in the example above: as you can see, the
message ``xsltApplyOneTemplate: fallback was not compiled'' is
one of those messages.

> > 	- overwrite the global state with the one created above
> > 	- (change libxml defaults)
> > 	- save my own global state
> > 	- restore previous global state
>   That sounds very messy. If you compile with thread you already have
> per thread global data so I don't understand what you're doing with this
> memcpy. 
Yes, I have per thread memory, but, __in the same thread__, more than one
``module'' is making use of libxml. More than once, in a big loop.
My problem is not due to concurrency.  I don't care anything about 
concurrency, the application in which the modules I'm talking about
are inserted is _not_ multithreaded (just one thread).
The purpose of the memcpy, like I tryed to explain in the last
email (probably with little success), is to isolate each module in 
its own context (since, being executed in the same thread, they
all share the same libxml globals). 
I'll try to explain it in other words: I have an application
built up by multiple modules. By ``module'' I mean a piece of binary 
data written by somebody I really don't know anything about for which 
I may not have the sources available. modules can be loaded, unloaded
added (from/to the application) or written by the user at any time 
(they are dlopened and dlclosed). 
A function from the module is executed when the module is first loaded 
(initialized) and then another function of the module is called iteratively 
in a big loop to ask the module to perform its own task.
I'm writing just one of these modules, and my module:
	- Neither when loaded or called can rely on global 
	  libxml variables being set to default values (some other
	  module may have changed libxml globals earlyer) 
	- Additionally, some modules may rely on some libxml
	  variables to have the same value from one iteration
	  of the big loop to the next one, so I cannot change
	  libxml global variables (remember, modules are sharing
	  the same global state, since they are run in the same
	  thread) in the loop,
	- unless I save the value of the variables before changing
	  their values. However, I don't know which libxml globals
	  were changed by other modules, so I need to save and
	  restore _all_ of them. Additionally, I don't want
	  to write a code that needs to be changed every time
	  a global variable is added or removed from libxml
	  sources, so I compile libxml2 with threading enabled 
	  (althought my application is not multithreaded) take the 
	  address of the global state and copy it somewhere else.
        - Additionally, I cannot rely on other modules being 
	  well-written for my own to work

>    Well I don't understand why you want to do that. if you have
> specific setup and you want to switch save the variable and restore
> them I really don't see why it's not appropriate !
I can't save just the variables I change:
	Module 1: wants to use its own memory handling routines,
	    and changes them
	MyModule: wants to use its own error handling routines
		- save old error handling routine
		- put my own
	    now, if it calls libxml it parses data using module
	    1 memory handling routines, which _won't_ work.
	    Additionally, I cannot clean up all the globals, 
	    since Module 1 _will_ be called again (we are in
	    a big loop), this time probably without setting
	    the memory handler.
The only alternative to rewriting all the modules and to exterminate 
every future programmer who does not restore libxml defaults on 
each iteration I can see is to store and restore _all_ global variables 
(correct me if I'm wrong - that's what I was asking, but looking for
valid alternatives). 

> >     highlited above) if I save and restore just them
> >     before and after running the module? 
>    Pleople are using libxslt in multithreaded apps without troubles
> nearly since the beginning. For the errors yes they are shared, 
> so far nobody provided code for something like libxml2 multithread
> support so it must be that nobody felt an urgent need for it.
so, I can assume the error handlers are the only global variables
that can be changed by a module and that I need to save and restore
to make sure I will not compromise another module usability? 
(like I said above, I don't have any problem with multithreading 
since I have one, single, thread)

> > Sorry for the long mail and sorry for the OT about libxml, but 
> > I really didn't know how to best split the mail.  Feel free to
> > answer me on any of the two lists.
>   I'm not sure I understand every aspects of your problems nor
> why you selected some solutions which looks rather complex.
I apologize if I haven't been clear enough or if I may sound rude.
I don't mean to be so. 

Thanks for your help anyway,
Carlo

-- 
  GPG Fingerprint: 2383 7B14 4D08 53A4 2C1A CA29 9E98 5431 1A68 6975
                        -------------
Mater artium necessitas.
	[Necessity is the mother of invention].