0bc1ca4045
libuv handles are tied to the event loop that created them. In order to perform IO, the handle must be on the thread with its home event loop. Thus, when as task wants to do IO it must first go to the IO handle's home event loop and pin itself to the corresponding scheduler while the IO action is in flight. Once the IO action completes, the task is unpinned and either returns to its home scheduler if it is a pinned task, or otherwise stays on the current scheduler. Making new blocking IO implementations (i.e. files) thread safe is rather simple. Add a home field to the IO handle's struct in uvio and implement the HomingIO trait. Wrap every IO call in the HomingIO.home_for_io method, which will take care of the scheduling. I'm not sure if this remains thread safe in the presence of asynchronous IO at the libuv level. If we decide to do that, then this set up should be revisited. |
||
---|---|---|
.. | ||
arch | ||
isaac | ||
jemalloc | ||
linenoise | ||
msvc | ||
sync | ||
util | ||
vg | ||
boxed_region.cpp | ||
boxed_region.h | ||
memory_region.cpp | ||
memory_region.h | ||
miniz.cpp | ||
rust_abi.cpp | ||
rust_abi.h | ||
rust_android_dummy.cpp | ||
rust_android_dummy.h | ||
rust_builtin.cpp | ||
rust_crate_map.cpp | ||
rust_crate_map.h | ||
rust_exchange_alloc.cpp | ||
rust_exchange_alloc.h | ||
rust_gc_metadata.cpp | ||
rust_gc_metadata.h | ||
rust_globals.h | ||
rust_gpr_base.h | ||
rust_log.cpp | ||
rust_rng.cpp | ||
rust_rng.h | ||
rust_run_program.cpp | ||
rust_test_helpers.cpp | ||
rust_type.h | ||
rust_upcall.cpp | ||
rust_util.cpp | ||
rust_util.h | ||
rust_uv.cpp | ||
rustrt.def.in |