[xslt] document re-use between contexts


We're using libxslt to create a large number of transaction files on
individual input files.  Up until recently everything's been great,
but I tried adding an extra document to the transform that contains
static schema information that's used for lookups in the .xsl and am
having some issues.  I add that already-parsed xmlDocPtr to my
transform context using xsltNewDocument().

The problem comes around when, after we've done an
xsltApplyStylesheetUser(), we dutifully call
xsltFreeTransformContext() on our context.  This function runs through
all of its documents and not only free()'s its xsltDocument, but also
the xmlDocPtr that was given to it using xsltNewDocument().  I'd
rather it skip the xmlFreeDoc() since I want to re-use it without
having to re-parse or copy the doc for each new context.

I'm not sure if we're doing something non-standard, but assuming not,
it seems to me that a new function or flag might be nice in order to
keep ownership of the xmlDocPtr that's used in xsltNewDocument.  Then,
during xsltFreeDocuments(), this flag could be checked before calling

I would be more than willing to contribute these changes... we'd
rather have them in the main libxslt distribution than support our own
patch.  But before creating a patch, any feedback would be
appreciated.  I propose:

struct _xsltDocument {
    struct _xsltDocument *next; /* documents are kept in a chained
    list */
    int main;                   /* is this the main document */
    xmlDocPtr doc;                 /* the parsed document */
    int staticDoc;      /* if set, don't xmlDocFree the doc */
    void *keys;               /* key tables storage */

xsltNewStaticDocument(xsltTransformContextPtr ctxt, xmlDocPtr doc)
   call xsltNewDocument
   set staticDoc = 1

There's already a memset(0,...) in xsltNewDocument so the default
value of staticDoc will maintain current behavior.

And finally, during the free, in addition to checking doc->main, check
doc->staticDoc before calling xmlFreeDoc().

Thanks for any comments,

jason haslup

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