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

[Jeff Burdges]

On Mon, 2016-03-21 at 20:39 +0100, Christian Grothoff wrote:

> For GNUnet's C code, I strongly believe the choice of going with an
> event loop and to not have any threads (but processes) is a good choice.

We're all only talking about abstraction layers on top of Metal IO
(mio), which provides the basic event loop most commonly used in Rust.  

It's true mio uses unsafe more than anyone likes, currently 79
occurrences, but that includes largely system calls, both declarations
and usages, as well as safe data types built using unsafe. 

Here is my cursory evaluation of the top-ish four asynchronous IO
abstraction libraries built on mio :

Coroutines 
https://github.com/dpc/mioco
- Most examples by far.  Okay docs :
  http://dpc.pw/mioco/mioco/index.html
- Nine contributors, quite active.
- Probably the most straightforward option, offers timers.
- There are some less developed coroutine libraries like 
  https://github.com/zonyitoo/coio-rs

State Machine
https://github.com/tailhook/rotor
- Best docs by far, including design blog, but fewer examples :
  https://tailhook.github.io/rotor/rotor/index.html
- Eight contributors, quite active.
- Interesting option, maybe simplifies memory management, maybe
clarifies logic overall, probably easier to debug, definitely more
boilerplate, and no obvious timers.

Futures 
https://github.com/carllerche/eventual_io
- No docs, but eventual has docs :
  https://carllerche.github.io/eventual/eventual/index.html
- Three contributors, seven if you consider eventual.  By mio guy
- Presumably similar to GNUNet's scheduler, except for possibly lacking
timers.
- Eventual looks like that abstraction about which Andrew spoke, but
overall probably too experimental. 

Promises 
https://github.com/dwrensha/gj 
- Some docs : http://docs.capnproto-rust.org/gj/index.html
- Just one contributor.  He works at Sandstorm.io
- Appears similar to GNUNet's scheduler, except for possibly lacking
timers. 

I suspect the human factors eliminate eventual_io and gj, leaving only
mioco or rotor.  I'm less impressed with rotor's readability after
actually reading some code using it, although I'd wager rotor would
prove easier to debug than mioco.  I think timers sound rather crucial
though, so that probably clenches it for mioco, although maybe they're
easy to tack onto rotor machines via mio.  

Also, I criticized mioco largely for advertising itself as green
threads, which I worried might make writing deadlocks easy, but it's
clearly coroutines and not green threads.  I'm curious about mioco'ss
tack handling, and if it incurs more overheard, but that's probably
irrelevant for us. 

It's ultimately Kelong's decisions of course, assuming GSoC accepts him,
but I'd probably recommend mioco too.  I still think futures/promises
matches the closest the GNUnet code I've seen, but coroutines is not so
far off, and mioco appears much more developed. 

I'll skim the X10 papers at some point soon.

Jeff

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