On Mon, Aug 07, 2006 at 03:25:13PM +0200, Stefan Behnel wrote: > Sure, I'm not questioning the first rule. I was serious. Would you consider > the above a viable solution or could you come up with a way to safe the > concurrency support in XSLT processing?
Well libxslt is thread safe by default. It's the fact of not using a subdict for each transformation which makes it non-safe. If you clearly point out that every XML/XSLT data should be kept in the same thread then yeah, I think you should be safe, but it also depends on the user not doing crazy things, and when it comes from threaded programming people will do crazy things without even realizing. The big claim of lxml was that it would be pythonic in removing the constrain for a programmer to keep track of the lifetime of XML object. You end up with having to track the thread 'owning' an object instead, which would be better for some apps but could turn nightmarish for others. Sorry I don't see a simple solution, and adding locking at the dictionnary access level would just kill performances in the general case. Daniel -- Daniel Veillard | Red Hat http://redhat.com/ [EMAIL PROTECTED] | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ _______________________________________________ xslt mailing list, project page http://xmlsoft.org/XSLT/ [email protected] http://mail.gnome.org/mailman/listinfo/xslt
