Marked instruction with std::maker::sync.

[felberj]

This is done to make it usable by multiple threads. Capstone claims to be 'Thread-safe by design', so this should work.

Note that there are two flaky tests: They sometimes fail with and without my commit.

test test::test_instruction_group_ids ... FAILED
failures:

---- test::test_instruction_group_ids stdout ----
	thread 'test::test_instruction_group_ids' panicked at 'Expected groups {1} does NOT match computed insn groups {110} with ', src/lib.rs:287:8
note: Run with `RUST_BACKTRACE=1` for a backtrace.

test test::test_syntax ... FAILED
failures:

---- test::test_syntax stdout ----
	thread 'test::test_syntax' panicked at 'index 86 out of range for slice of length 8', src/libcore/slice/mod.rs:735:4
note: Run with `RUST_BACKTRACE=1` for a backtrace.

[felberj]

I just realised this needs more work:

error[E0277]: the trait bound `*mut capstone_sys::cs_detail: std::marker::Sync` is not satisfied in `capstone::Insn`
   --> src/lib.rs:190:9
    |
190 |         thread::spawn(move || {
    |         ^^^^^^^^^^^^^ `*mut capstone_sys::cs_detail` cannot be shared between threads safely
    |
    = help: within `capstone::Insn`, the trait `std::marker::Sync` is not implemented for `*mut capstone_sys::cs_detail`
    = note: required because it appears within the type `capstone_sys::cs_insn`
    = note: required because it appears within the type `capstone::Insn`

Do you think I can just edit this?

[tmfink]

The Capstone C library may be "thread safe", but that does not mean the capstone-rs Rust bindings are thread-safe. In order to be thread-safe, Rust has more stringent requirements.

As you noticed, it is unsafe to make Instructions Sync, which would imply that it is safe to access from multiple threads.

[tmfink]

@felberj could you give me more details on your the setup? I'm unable to reproduce this issue.

Information:

1. Operating system version
2. CPU architecture
3. capstone-rs features (if any)

As is, I can't merge this change. It would be incorrect to mark these structs as Sync.

Out of curiousity, what are you trying to do that would require Instructions to be Sync?

[felberj]

Thank you for looking into it:

Out of curiousity, what are you trying to do that would require Instructions to be Sync?

I want to analyse instructions from multiple threads, so this is what I wanted to do. What I will probably do now is copy all the information in my own struct.

@felberj could you give me more details on your the setup? I'm unable to reproduce this issue.

If you mean the thread::spawn(move || { error, this was just me trying to send the Instruction over to another thread with this merge request merged. But it did not work.

If you mean the test errors:

Operating system version

macOS

CPU architecture

x86

capstone-rs features (if any)

well, I just invoked cargo test on HEAD multiple times and sometimes it failed.

[tmfink]

@felberj what version of macOS are you running? Also, what's the output of commands:

uname -a
git rev-parse HEAD

[felberj]

23:25[capstone-rs]$ uname -a
Darwin MacBook-Pro-2.local 16.7.0 Darwin Kernel Version 16.7.0: Wed Oct  4 00:17:00 PDT 2017; root:xnu-3789.71.6~1/RELEASE_X86_64 x86_64
23:25[capstone-rs]$ git rev-parse HEAD
fe64e02067f4df0bb336452c87f9ccaa619f71c9

macOS Sierra

[tmfink]

Closing because current pull request does not solve issue.

Further discussion should occur in issue #26