"Wiedmann, Jochen" wrote: > > > As Dean said, it doesn't make sense to make every call > > thread-safe. This > > would be a huge overhead, and most people wouldn't need it > > anyway (locking > > is always more efficient when done in an application-aware way). > > Sorry, but I can't follow you here. Based on the assumption > of a single parser instance per thread I see no reason for > locking at all. And if parser instances are shared by threads, > its surely the task of the application to implement locking. > > So why do you see a performance problem? (Of course I follow > your arguments against MSXML.) >
I think what you're saying is basically correct. There's only a performance problem, if people try to share parser instances between threads, and then insist that all function calls be thread-safe. Then, we would have to implement locking on every function call, and this is costly (particularly in Java, but there's also a cost, of course, in C++). Yes, there are people out there that when they ask "is Xerces thread-safe?" really are asking "why can't I access the same parser/DOM/etc. from multiple threads, and make any function calls I want to, and have it all work?". This question is asked so often, that there is a FAQ on it (I'll repeat it here, for the benefit of all, and so that searches of the mail archive will turn it up!) :-) ===================== Is Xerces-C thread-safe? This is not a question that has a simple yes/no answer. Here are the rules for using Xerces-C in a multi-threaded environment: Within an address space, an instance of the parser may be used without restriction from a single thread, or an instance of the parser can be accessed from multiple threads, provided the application guarantees that only one thread has entered a method of the parser at any one time. When two or more parser instances exist in a process, the instances can be used concurrently, and without external synchronization. That is, in an application containing two parsers and two threads, one pareser can be running within the first thread concurrently with the second parser running within the second thread. The same rules apply to Xerces-C DOM documents - multiple document instances may be concurrently accessed from different threads, but any given document instance can only be accessed by one thread at a time. DOMStrings allow multiple concurrent readers. All DOMString const methods are thread safe, and can be concurrently entered by multiple threads. Non-const DOMString methods, such as appendData(), are not thread safe and the application must guarantee that no other methods (including const methods) are executed concurrently with them. > Jochen
