[Top][All Lists]

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

Re: [GNUnet-developers] [GSoC] Question on "Rust implementation of GNUne

From: Jeff Burdges
Subject: Re: [GNUnet-developers] [GSoC] Question on "Rust implementation of GNUnet utils" project
Date: Mon, 25 Apr 2016 00:30:39 +0200

An update on this :

It appears gj has been split into a separate generic promises library gj
and an IO library gjio :

At first, that sounds great because we liked that separation in
eventual, but he also dropped mio and does the system calls himself now:

That makes me nervous, as mio solved thing gjio probably does not, but
it's not a show stopper.  We can still move from gj to eventual more
easily than the reverse.


On Thu, 2016-04-14 at 15:25 +0200, Jeff Burdges wrote:
> I've learned slightly more about our asynchronous IO options.  I'll give
> some notes below, but the short version is :
> We should *first* trying using gj for a Rust implementation of GNUnet
> utils because it's actually the most restrictive callback-like event
> loop.  It'll be easier to migrate from gj to anything else. 
> Jeff
> Notes :
> There are interesting features of both eventual_io vs gj : 
> - Eventual provides the abstraction layer that Christian and Andrew
> expressed an interest in. 
> - Cap'n proto has an interesting RPC facility built on gj.
> And they differ with how they interact with threads :
> - Eventual imposes Send bounds frequently, so that types can move
> between threads.  As it better abstracts thread pools, but you must use
> Arc<> types lots.
> - Anywhere that eventual needs an Arc<>, gj uses its non Send cousin an
> Rc<>.  
> It follows gj cannot interact as flexibly with threads, but really Rc<>
> should be viewed as "more thread safe" because you're forbidden from
> sharing them between threads at all.  In particular, it's easier to
> migrate code based on gj over to eventual that the reverse. 
> It's easier to make eventual code run on top of another thing, like say
> a state machine, but that's unlikely.  And porting gj code to eventual
> code appears really trivial if one wishes to do is that way.  And gj's
> restrictions would help if making the transition more manually.
> We should hold off starting the Cap'n proto RPC conversation since it
> does not pertain to existing GNUnet services, but it add extremely
> interesting long-term options. 
> There is a good chance Rust gains higher-kinded types within the next
> couple years, which should enable eventual to be polymorphic over
> bounds, and might precipitate a merger of eventual and gj.  
> > Futures 
> >
> > - No docs, but eventual has docs :
> >
> > - Three contributors, seven if you consider eventual.  By mio guy
> > Promises 
> > 
> > - Some docs :
> > - Just one contributor.  He works at
> We should probably avoid coroutines, meaning no mioco, since we should
> not need that messy extra flexibility for GNUnet's proposes.  Also,
> Christian expressed reservations about building on APIs significantly
> more powerful than necessary.
> > Coroutines 
> >
> > - Most examples by far.  Okay docs :
> >
> > - Nine contributors, quite active.
> There are folks singing the praises of state machines, like
> And they do have greater advantages in Rust, like helping eliminate even
> Rc<> wrappers.  I suspect however that our code in GNUnet is largely
> higher level than where they really shine. 
> > State Machine
> >
> > - Best docs by far, including design blog, but fewer examples :
> >
> > - Eight contributors, quite active.
> _______________________________________________
> GNUnet-developers mailing list
> address@hidden

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

reply via email to

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