[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[GNUnet-developers] Asynchronous IO in Rust

From: Jeff Burdges
Subject: [GNUnet-developers] Asynchronous IO in Rust
Date: Mon, 20 Mar 2017 15:38:42 +0100

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

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 for sure, but I do
not know if we'd use too.
There is more documentation available at 

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


p.s.  Asynchronous IO stack components are mostly listed at
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.

mio - Actually handles epoll/kqueue.  And windows?

tokio-io - Abstractions on top of futures-rs for reading and writing.

tokio-core - This is where futures-rs and mio actually meet.

tokio-uds & mio-uds - Unix domain sockets !!

? tokio-process & tokio-signal - Process management.

? tokio-curl - Asynchronous interface to libcurl

tokio-timer - Timer functionality.

tokio-service - Abstractions on top of futures-rs for "services".

tokio-middleware - Service-like interface for logging and timers.

tokio-proto - This is where tokio-core and tokio-service meet.
  "a protocol is a way of providing or consuming a service".

tokio-retry - asynchronous retry behaviors.

? tokio-tls - TLS, maybe a better choice will appear.

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]