Hi. I'm the author of mioco, and I was toying with futures + tokio, and had the same idea as this project. I've found it when doing some initial research googling. I wonder what are your plans and would you accept some bigger PRs if I was to submit them.

I have some ideas already:

• coroutines could implement Future, but maybe it could also be Stream
• instead of passing SchedThunk, I was thinking about exposing static functions, that under the hood use task_local values (http://alexcrichton.com/futures-rs/futures/task/index.html); before resuming a coroutine, a Future wrapping it, would set task_local data for given coroutine, and in the coroutine itself it would be possible to call fringe-future::yield(), fringe-future::spawn(/* new coroutine function */)`, etc. ; that would be the analogous to std::thread API, which mioco emulates, and I think users are most happy with it as they don't have to pass any object around.
• support for tokio-core types with a macro (or a wrapping type), that would suspect after io returned WouldBlock
• I think that a name of cofuture or something would be shorter and better; user will not care if under the hood it's context-rs or libfringe.