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

Libmagic can not share handles across threads safely #20

Open
unclebadtouches opened this issue Jan 4, 2016 · 3 comments
Open

Libmagic can not share handles across threads safely #20

unclebadtouches opened this issue Jan 4, 2016 · 3 comments

Comments

@unclebadtouches
Copy link

I'm getting a crash in libmagic when using this library with multiple goroutimes. I suspect the reason is because this library keeps a single global handle that is used for all libmagic calls. A quick google search tells me that libmagic handles cannot be shared across threads.

Perhaps a better way to deal with this would be to wrap the libmagic handle as an opaque object that is passed back to the caller from Open(). Close() would also need a receiver or take an opaque handle as an argument.

@joeshaw
Copy link

joeshaw commented Feb 2, 2016

While I haven't seen crashes, I've seen similar thread-safety issues, like getting back "image/jpegimage/jpeg" for a call to TypeByBuffer.

@rakyll
Copy link
Owner

rakyll commented Feb 2, 2016

We can proxy all calls thorough an operating system thread locked goroutine or update the samples that users are supposed to use runtime.LockOSThread.

@joeshaw
Copy link

joeshaw commented Feb 3, 2016

I worked around it by wrapping my calls to TypeByBuffer in a mutex. Adding that to the library is another possible option, though it limits throughput.

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

No branches or pull requests

3 participants