]> git.lizzy.rs Git - rust.git/commit
auto merge of #8631 : anasazi/rust/homing-io, r=brson
authorbors <bors@rust-lang.org>
Wed, 21 Aug 2013 00:12:09 +0000 (17:12 -0700)
committerbors <bors@rust-lang.org>
Wed, 21 Aug 2013 00:12:09 +0000 (17:12 -0700)
commit0bc1ca404539102065ee0757944ce2288db4cb32
treeb52c5d124c4321244e781047080edb4153381fca
parent3cd978fbc75a691a144dcafe99a08531a424fcd0
parent35e844ffc1e3c022e868817ad1c548b900db800a
auto merge of #8631 : anasazi/rust/homing-io, r=brson

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.
src/libstd/rt/rtio.rs
src/libstd/rt/uv/uvio.rs