gnunet-developers
[Top][All Lists]
Advanced

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

Re: [GNUnet-developers] Asynchronous IO in Rust


From: lurchi
Subject: Re: [GNUnet-developers] Asynchronous IO in Rust
Date: Wed, 22 Mar 2017 00:08:23 +0100

On Mo, 2017-03-20 at 15:38 +0100, Jeff Burdges wrote:
> 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.

I'm planning to write a secushare API in Rust which uses the
Future/Stream types from the futures crate in combination with a Core
event loop (tokio_core crate).
We are using Qt, too through the Rust bindings from https://github.com/
White-Oak/qml-rust, so integrating Qt's event loop with GNUnet is not
our goal right now. In the end it should be possible to integrate any
event loop with GNUnet of course.

Did I understand it correctly that modifying the GNUnet scheduler means
you're planning to not do IPC with the GNUnet services from Rust
anymore? That would be good news to me because it's easier to maintain
the Rust bindings when they call the API functions (which are supposed
to change rarely).

> 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? 

I was playing around a bit with the GNUnet scheduler already to open it
up to other event loops (see the attached patch). It's a quick try and
probably needs to be improved. Basically I introduced two new API
functions:

- GNUNET_SCHEDULER_set_work_callback: allows setting a callback which
is called after select returned. The callback is expected to schedule a
task in the external event loop. After that the GNUnet event loop
blocks

- GNUNET_SCHEDULER_do_work: the scheduled task is expected to run this
function, so all the available GNUnet tasks can be executed. After that
GNUnet's event loop continues to run

When it comes to how to schedule a task in the tokio_core event loop, I
was thinking of a 'Stream' (https://docs.rs/futures/0.1.11/futures/stre
am/trait.Stream.html) which is spawned before the GNUnet scheduler is
started. Communication with that stream should be possible with the
task::park and task::unpark (see https://docs.rs/futures/0.1.11/futures
/task/fn.park.html).

This is my first idea and it's possible that I overlooked something,
the tokio.rs stuff is not the easiest to see through.

> 
> 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.

So far tokio_core seemed sufficient to me.

> 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.

I'm confused. Why would GNUnet need tokio-tls or trust-dns?

lurchi.

Attachment: external_event_loop.patch
Description: Text Data

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


reply via email to

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