Use Mutex for runtime and client

[milesgranger]

Take it or leave it, this ought to fix thread local issues.

I didn't look too much into the change in the examples/script.py timing, but this doesn't have any discernible decrease in performance, but do note that even on main branch, the timings seem out of date from what's on README.

[martindurant]

the timings seem out of date from what's on README.

This is as measured on my home wifi, which doesn't particularly like to have loads of connections in flight :)

[martindurant]

Does this have the effect of having the client and runtime exist globally and only accessible from one thread at a time? If so, I specifically don't want that, because threads should be able to communicate independently, giving GIL-free parallelism to something like dask.

(don't worry about the CI fail - wheel upload should only happen on main-branch merge/pushes, not on PRs)

[milesgranger]

Ah, well that's right, it would be one instance per globally. However, from my understanding of it, the runtime itself is using one worker thread which exists inside the block of releasing the GIL so as far as being GIL-free this doesn't change anything, but if you added more worker threads then there would be contention for the runtime and/or client.

[martindurant]

It should be using the in-thread runtime (i.e., concurrent as opposed to parallel) for the IO tasks - I picture it as working exactly like python asyncio, with which you can also in theory run an event loop in each thread. https://docs.rs/tokio/0.3.5/tokio/runtime/struct.Builder.html#method.new_current_thread