[Top][All Lists]

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

Re: [GNUnet-developers] Asynchronous IO in Rust

From: Jeff Burdges
Subject: Re: [GNUnet-developers] Asynchronous IO in Rust
Date: Wed, 22 Mar 2017 02:43:12 +0100

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
> 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' (
> 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
> /task/fn.park.html).
> This is my first idea and it's possible that I overlooked something,
> the 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.


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

reply via email to

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