[GNUnet-developers] Asynchronous IO in Rust

[Jeff Burdges]

Christian has expressed an interest in GNUnet becoming modular over
scheduler for asynchronous IO operations.  There are two primary targets
for this : 
-  Qt's scheduler does not play well with others.  We must support it
for Qt applications.
-  The Rust community rejected all C schedulers as unsafe, or more
precisely "slow if wrapped safely", so they wrote their own asynchronous
IO stack.

We should imho target the Rust scheduler first because doing so will be
more fun, so I'll talk about doing that.  The question is : 

Where should we plug into their asynchronous IO stack?  Including, where
does their stack look most like GNUnet's existing asynchronous IO
stack? 

In essence, the two choices is between living on top of tokio-core
directly, or using the higher level abstractions in tokio-proto too.
We'd use https://docs.rs/tokio-core/0.1.6/tokio_core/ for sure, but I do
not know if we'd use https://docs.rs/tokio-proto/0.1.1/tokio_proto/ too.
There is more documentation available at
  https://tokio.rs/docs/getting-started/tokio/ 

I'm not yet familiar with the recent changes to the GNUnet scheduler,
but so far either choice looks doable really. 

Jeff

p.s.  Asynchronous IO stack components are mostly listed at 
  https://tokio.rs/docs/going-deeper/third-party/
  https://github.com/tokio-rs/
I skimmed their Cargo.toml files to get a rough idea of dependencies, so
this list is generally ordered so that later depend on earlier.  This
looks like a lot of libraries, but many are small and/or nice
abstractions that should compile down to nothing. 

Anything marked with a ? is something GNUnet overall needs, but Rust
services should not need because another service like gnunet-arm or
transport does everything we need.  In particular, I think TLS and DNS
might push us up the stack onto tokio-proto, but other GNUnet processes
do everything we need there.

futures-rs - Abstracts building state machines.
  http://alexcrichton.com/futures-rs/futures/

mio - Actually handles epoll/kqueue.  And windows? 
  https://carllerche.github.io/mio/mio/index.html

tokio-io - Abstractions on top of futures-rs for reading and writing.
  https://tokio.rs/blog/tokio-io/
  https://docs.rs/tokio-io/0.1.0/tokio_io/

tokio-core - This is where futures-rs and mio actually meet. 
  https://docs.rs/tokio-core/0.1.6/tokio_core/
  https://github.com/tokio-rs/tokio-core

tokio-uds & mio-uds - Unix domain sockets !!
  https://github.com/tokio-rs/tokio-uds
  https://github.com/alexcrichton/mio-uds

? tokio-process & tokio-signal - Process management. 
  https://github.com/alexcrichton/tokio-process
  https://github.com/alexcrichton/tokio-signal

? tokio-curl - Asynchronous interface to libcurl
  https://github.com/tokio-rs/tokio-curl

tokio-timer - Timer functionality.
  https://github.com/tokio-rs/tokio-timer

tokio-service - Abstractions on top of futures-rs for "services".
  https://docs.rs/tokio-service/0.1.0/tokio_service/trait.Service.html
  https://github.com/tokio-rs/service-fn

tokio-middleware - Service-like interface for logging and timers.
  https://tokio-rs.github.io/tokio-middleware/tokio_middleware/

tokio-proto - This is where tokio-core and tokio-service meet.
  "a protocol is a way of providing or consuming a service".
  https://docs.rs/tokio-proto/0.1.1/tokio_proto/
  https://github.com/tokio-rs/tokio-proto

tokio-retry - asynchronous retry behaviors.
  https://docs.rs/tokio-retry

? tokio-tls - TLS, maybe a better choice will appear.
  https://github.com/tokio-rs/tokio-tls

? trust-dns - DNS resolution, maybe kinda heavy.

signature.asc
Description: This is a digitally signed message part