I hope to be using ns_xml soon, but haven't looked at it yet.
You can probably assure over time that ns_xml is thread safe, but if you find that the underlying libxml/t isn't then, well there's another alternative to making something thread safe that's not. And that is to only use it from one thread.
I had a similar problem with swish-e a few weeks back. It was rewritten to be thread safe but there had been no real testing of it. Plan A was to go for it, with the typical AOLserver embeddeding, but there was a Plan B. Plan B was to use Rob Mayoff's threadpool code and create a ns_swish-e server that runs in it's own AOLserver thread. Code in other threads that need swish-e services would create a swish-e request on a swish-e queue that get's handled in the separate swish-e thread. One way of looking at that is that it is letting Rob handle all your mutexes for you. Swish-e has a reasonable API for that. There's an initial call, that gives you a swish-e handle that you then return to the other calls. I don't know if ns_xml could be set up the same way.
Anyway, that was Plan B.
