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

[Andrew Cann]

Another option would be to use mioco. Mioco let's you write blocking/threaded
style code but underneath uses green threads and non-blocking IO. This is
similar to what you'd see in Go.

 - Andrew

On Mon, Mar 21, 2016 at 05:44:42PM +0100, Jeff Burdges wrote:
> 
> We first need to get your application in to Google by whatever deadlines
> they have.  
> 
> I'm seemingly listed as a mentor now and can see GNU applications when I
> access their site at : https://summerofcode.withgoogle.com/dashboard/
> 
> If you go there, or to this google-melange.com site, can you see a way
> to enter the application?  If you need to identify me to them, my
> account there is address@hidden  I donno if we need to provide you
> with something first though.
> 
> 
> On Mon, 2016-03-21 at 15:03 +0100, kc wrote:
> 
> > Thank you for the insight, no wonder I couldn't find any Rust code!
> > 
> > I also feel starting with the second option is better since it has a
> > mucher lower entry barrier so I can start hacking ASAP.
> 
> > I see that GNS lookup, peer info listing and identity ego lookups are
> > implemented. Do you think adding async IO to those functionalities by
> > mid-term evaluation is feasible? What would you like to see by the end
> > of the GSoC? Perhaps finish the "Next on the list" items?
> 
> I think one reasonable goal might be :
> 
> Use mio via rotor/eventual_io/gj to provide the asynchronous IO
> functionality of GNUNet utils scheduler and adapt the peer info protocol
> from gnunet-rs to use it. 
> 
> We can substitute peer info with whatever Christian thinks is the most
> fundamental layer, but that's the one I'd expect. 
> 
> > I've used asyc IO in a few projects before. For instance I've
> > goroutines/channels (from golang) to implement a few distributed
> > algorithms such as for Byzantine agreement, leader election and mutual
> > exclusion. I also used some of the Haskell async libraries
> > namely Control.Concurrent for a project where we had to implement the
> > log-structured merge-tree. Finally, I've used pthreads when I was
> > working on an enterprise backup system. I don't have any async IO
> > experience in Rust but the paradigms shouldn't be to different.
> 
> Ok great. 
> 
> > Regarding those libraries, I can't say I'm familair with the state
> > machine based ones like rotor. On the other hand, I'm familair with the
> > concept behind Futures and Promises which is what gj and eventual_io
> > uses. Is there a preferred async IO model for GNUnet-rs or it's still
> > up for discussion?
> 
> I've little opinion myself.  I'd just like it to be easier to read than
> the current GNUnet utils stuff.  I think that'll be the case with any of
> gj, eventual_io, or rotor. 
> 
> I think the question is really : What model do you like?  And do you
> have any opinions about what fits best with what situations?  I'll look
> closer at the options and ask Christian for his opinion though too. 
> 
> Jeff
> 
>

signature.asc
Description: Digital signature