Re: [GNUnet-developers] Asynchronous IO in Rust

[Jeff Burdges]

On Wed, 2017-03-22 at 00:12 +0100, lurchi wrote:
> 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.

I suppose qml-rust runs Qt in a separate thread.

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

No.  Ain't necessarily so easy to analyze the memory safety of any given
C API that uses the GNUnet scheduler.  This might remain problematic
even if the GNUnet scheduler were running on top of mio, tokio, etc.  

> 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

Sounds interesting.  I'm happy to look deeper into it.

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

I've no idea right now.  :) 

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

I took the long way of saying it does not.

Jeff

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