Hi Sidnei, Sidnei da Silva wrote:
On 6/1/07, Stefan Behnel <stefan_ml@behnel.de> wrote:
Sidnei da Silva wrote:
This is using the 1.2.1 release.
For a quick test, try with 1.3beta or the current trunk. No guarantee, though, especially the trunk is not necessarily in a perfect production state.
I wish I could compile trunk, but I haven't figured out a resolution to that issue with MSVC. :(
Ever tried MinGW? I read in a couple of posts that it works pretty well with Python modules - not sure about Pyrex and setuptools, though.
I've updated to libxml2-2.6.27 and libxslt-1.1.19 and it hasn't crashed so far. I've mailed Igor Zlatkovic to see if he will be building binaries for the latest libxml2/libxslt anytime soon.
Well, if 2.6.27 works for your code, then that's fine. I just said there seem to be certain XPath expressions that make it crash. If you don't hit that problem, you should be on the safe side.
Sorry if this doesn't help, but trying other versions is as much as I can propose at the moment, especially if it's urgent.
That was good advice, and it seems to have solved the immediate issue. Thank you a lot!
It's actually really hard to keep lxml working across various different libxml2 and libxslt versions. We can only try to keep stuff that crashes libxml2 out of lxml itself, but we can't always keep users from writing stuff that crashes certain versions.
Ah, one last thing: I know, you're not testing threads for fun but for performance, but if that doesn't prove reliable for your application, you can still switch them off with --without-threading. Reliability is usually more important than performance for production.
Is there any document describing the effects of --without-threading? I guess it's safe to enable that flag if you are sure you won't share objects between threads?
That's not documented. It just disables all threading code in lxml, meaning, it never frees the GIL and thus prevents libxml2/libxslt code from running concurrently. Stefan