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

Rust bindings #61

Closed
luizirber opened this issue Oct 27, 2020 · 5 comments
Closed

Rust bindings #61

luizirber opened this issue Oct 27, 2020 · 5 comments

Comments

@luizirber
Copy link
Contributor

luizirber commented Oct 27, 2020

Hi, thanks for the great library!

I started two crates for wrapping the C FFI for using in Rust, one is the unsafe low-level bindings (bitmagic-sys) and another a safe/high-level/closer to Rust usage, based on the API of fixedbitset (bitmagic), but I intend to expose more methods over time.

Overall it is already working, after I commented out a line in cmake. The big problem I'm having is that if I run tests with more than 1 thread, the C++ exception emulation with longjmp/setjmp creates memory corruption. I'm looking into that to see what is going on...

I didn't register the crates in crates.io because I wanted to check if you first to see if that's OK, and I would also like to try to use the crate a bit more before registering anyway.

@tlk00
Copy link
Owner

tlk00 commented Nov 8, 2020

longjmp crash is an unfortunate bad news for threading programs..
I experimented with Java/JNI integration and it worked for me.

Did you figure out why it is happening in your case?
setjmp-longjmp is supposed to be happening within one thread, per-thread (if things work as planned)

@tlk00
Copy link
Owner

tlk00 commented Nov 8, 2020

Oh, never mind, i see what is going on

static jmp_buf ex_buf__;

is one shared point for all threads, thus needs to be communicated via TLS.
It is indeed seems to be a bug.

@luizirber
Copy link
Contributor Author

Oh, never mind, i see what is going on

static jmp_buf ex_buf__;

making it

  • thread_local jmp_buf ex_buf__; fixes my problem, but that requires C++11.
  • __thread jmp_buf ex_buf__; also works, but depends on GCC or Clang.
  • __declspec(thread) jmp_buf ex_buf__; seems to be the Windows idiom

(all options from https://en.wikipedia.org/wiki/Thread-local_storage#C_and_C++)

@tlk00
Copy link
Owner

tlk00 commented Nov 8, 2020

Yep, that is what i had in mind.
Please feel free to submit a patch (or let me know I would do it).

Thank you again for bringing it to attention!

@tlk00
Copy link
Owner

tlk00 commented Nov 9, 2020

Fix propagated, closing.

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

2 participants