You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
crewjam
changed the title
dont pollute the libxmlsec/libxml2 global state
dont pollute the libxmlsec/libxml2 global state with error handlers
Dec 23, 2015
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.The text was updated successfully, but these errors were encountered: