[Solved] QDomDocument::setContent and threads
-
Hi everyone,
the documentation of "QDomDocument::setContent":http://qt-project.org/doc/qt-4.8/qdomdocument.html#setContent states that the method is not reentrant. However, in the source code of Qt 4.8 I can find nothing that warrants such a restriction. There don't seem to be any global variables in use and it certainly doesn't modify its own code.I'd really like to use setContent in a multi-threaded environment (Edit for clarification: each thread has separate data). So my question is, what makes setContent non-reentrant? What kind of errors should I expect if multiple threads call it simultaneously, but with separate data?
Thanks in advance,
Ben -
[quote author="KA51O" date="1348651025"]setContent modifies the content of your DomDocument[/quote]
You mean the instance of QDomDocument I call the method on? I certainly hope it will be modified!
All joking aside, this doesn't break reentrancy. A function is reentrant if it can be safely called by multiple threads as long as each thread has its own data. The only situations I know of where reentrancy is broken are
- Modification of shared (usually global) data during execution of the function
- Modification of the function's code itself
- Calling a non-reentrant procedure
Since all my threads would have their own QDomDocument instance (I updated the original post to mention that), data to parse, error messages to fill and so on, the issue you are pointing out doesn't apply. Either the docs are outdated or there's some global variable (or call to non-reentrant function) I haven't found in the source code yet.
-
To answer my own question:
Prior to posting the question, I already thought about implicit sharing, but couldn't find QDomDocument in the "list of implicitly shared classes":http://doc.qt.digia.com/stable/implicit-sharing.html#list-of-classes. What I didn't think of was explicit sharing, and what do you know, the documentation of QDomDocument's parent class, "QDomNode":http://qt-project.org/doc/qt-4.8/qdomnode.html says that all its copies are explicitly shared. So that's the shared state that makes QDomDocument::setContent non-reentrant. At least I hope that's the only reason.
Anyway, if anybody's wondering: As long as you use new, uncopied instances of QDomDocument in each thread, it should be safe to use the setContent method in multiple threads simultaneously.