Using a global error stack is not thread safe.

[NHDaly]

The current global XML_GLOBAL_ERROR_STACK is not thread safe.

If two different threads are each parsing XML and each encounter an error, this can encounter race conditions. They could be as benign as hitting this "unknown error of libxml2" line instead:

EzXML.jl/src/error.jl

Lines 76 to 77 in 57ffce2

	if isempty(XML_GLOBAL_ERROR_STACK)
	error("unknown error of libxml2")

or they could be arbitrary errors from simultaneous mutation and reading of the vector, including possibly a crash.

---

I think a decent suggestion for a fix could be to write the error to a task-local variable instead of writing it to the global vector, and then read the result out of the task local storage?

cc @kpamnany, @d-netto

[NHDaly]

Note: we are encountering a race condition in our application, which we think might trace back to this package, though we still aren't sure. In the process of investigating that, we found the above issue just from reading the code. We haven't experienced any issues with this directly, as far as we know.

[nhz2]

From what I can tell, the underlying C library is not threadsafe, so this package doesn't attempt to be threadsafe either. Maybe this should be better documented?

[NHDaly]

Oh interesting! If that's true, it would be very good to document that, indeed!! 👍

We ended up dropping the package from our project, but documenting it would be great for others who may encounter the same issue. Thanks!