# The XML C parser and toolkit of Gnome

## Thread safety

Developer Menu

- Main Menu
- Reference Manual
- Code Examples
- XML Guidelines
- Tutorial
- The Reader Interface
- ChangeLog
- XSLT
- Python and bindings
- libxml2 architecture
- The tree output
- The SAX interface
- Memory Management
- I/O Interfaces
- The parser interfaces
- Entities or no entities
- Namespaces
- Upgrading 1.x code
- Thread safety
- DOM Principles
- A real example
- flat page, stylesheet

API Indexes

- Alphabetic
- Constructors
- Functions/Types
- Modules
- Symbols

Related links

- Mail archive
- XSLT libxslt
- DOM gdome2
- XML-DSig xmlsec
- FTP
- Windows binaries
- Solaris binaries
- MacOsX binaries
- lxml Python bindings
- Perl bindings
- C++ bindings
- PHP bindings
- Pascal bindings
- Ruby bindings
- Tcl bindings
- Bug Tracker

Starting with 2.4.7, libxml2 makes provisions to ensure that concurrent threads can safely work in parallel parsing different documents. There is however a couple of things to do to ensure it:

- configure the library accordingly using the --with-threads options
- call xmlInitParser() in the "main" thread before using any of the libxml2 API (except possibly selecting a different memory allocator)

Note that the thread safety cannot be ensured for multiple threads sharing the same document, the locking must be done at the application level, libxml exports a basic mutex and reentrant mutexes API in <libxml/threads.h>. The parts of the library checked for thread safety are:

- concurrent loading
- file access resolution
- catalog access
- catalog building
- entities lookup/accesses
- validation
- global variables per-thread override
- memory handling

XPath is supposed to be thread safe now, but this wasn't tested seriously.

Daniel Veillard