The `wasmtime::Store` type should be thread-safe

[alexcrichton]

As proposed in #708 the Store type in the wasmtime API should be thread-safe, meaning it should implement both Send and Sync. Currently, however, it has a few items that are not thread safe and/or need audits:

• The global_exports field is an Rc-protected data structure used by wasmtime internals. I don't know myself what it would take to remove this, but @sunfishcode looks like he does in Replace global-exports mechanism with caller-vmctx mechanism #390
• The signature_cache field requires interior mutability and currently uses a RefCell. While this could be switched to a Mutex I think it would be best to avoid this altogether. I don't personally know why this field exists, @yurydelendik do you know why it's here?
• The context field has a contained compiler field which has a number of issues. Namely Rc and RefCell are not thread safe (but can be swapped for Arc/Mutex if necessary), but the underlying Compiler type has a number of trait objects, raw pointers, etc, which would need auditing. I think the solution here is going to be making Compiler itself threadsafe by redesigning it's internals.

[yurydelendik]

signature_cache shall be a common storage across all imports/exports/module that are interact between each other to maintain common database of SignatureId -> Signature. The Compiler type contains signatures field to do the reverse operation, which is needed for codegen.

[Demi-Marie]

@alexcrichton why is this impossible?

[alexcrichton]

@demimarie-parity the way things are set up right now you instantiate Instance structures into a Store. The Store keeps a handle on each Instance, so effectively a Store stores each Instance. This is done to keep each Instance alive since we don't have a GC right now to otherwise understand when there are no references to an Instance.

Instances themselves are fundamentally not Sync because operations like global get/set aren't atomic. They're ideally Send, however, but with the Rc that we're using for memory management that forces them to not be Send.

The current state of affairs is that basically Store stores enough instance-local information that it can't be shared across threads because instances can't be shared across threads. There may still be internal refactorings or possible designs to fix this, but overall our threading story isn't great right now unfortunately.

[Demi-Marie]

@alexcrichton what if we used Arc instead? I imagine that reference count operations are not in hot paths.