whenever a golang thread invokes startProcessingXML() we take over the libxmlsec error handler (which is process-global) and the libxml2 error handler (which is per-thread)
If other packages are using cgo and libxml2 or libxmlsec in the same process we'll possibly break 'em, which isn't nice.
Part of the right solution is to have a c function invoked from stopProcessingXML() which unregisters our libxml2 handler.
For libxmlsec, the problem is subtler because we don't know if another goroutine might be calling xmlSecErrorsSetCallback somewhere. Ugh.
savp-RP
commented
4 years ago
whenever a golang thread invokes startProcessingXML() we take over the libxmlsec error handler (which is process-global) and the libxml2 error handler (which is per-thread)
If other packages are using cgo and libxml2 or libxmlsec in the same process we'll possibly break 'em, which isn't nice.
Part of the right solution is to have a c function invoked from
stopProcessingXML()which unregisters our libxml2 handler.For libxmlsec, the problem is subtler because we don't know if another goroutine might be calling
xmlSecErrorsSetCallbacksomewhere. Ugh.