Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

dont pollute the libxmlsec/libxml2 global state with error handlers #7

Open
crewjam opened this issue Dec 23, 2015 · 1 comment
Open

Comments

@crewjam
Copy link
Owner

crewjam commented 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.

@crewjam crewjam changed the title dont pollute the libxmlsec/libxml2 global state dont pollute the libxmlsec/libxml2 global state with error handlers Dec 23, 2015
@Dexus Dexus mentioned this issue Dec 13, 2017
@savp-RP
Copy link

savp-RP commented Feb 20, 2020

Do we have any fix for this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants