[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: Kelong Cong
Subject: Re: [GNUnet-developers] [GSoC] Question on "Rust implementation of GNUnet utils" project
Date: Tue, 22 Mar 2016 01:52:38 +0100
User-agent: K-9 Mail for Android

This is a really useful discussion and thank you for the summary Jeff.

A small comment on mioco, it does look a bit like goroutines. But I suspect that it doesn't do deadlock detection. Goroutines does some deadlock detection by having a runtime, not sure which deadlock detection algorithm it uses though.

I feel deciding on the async abstraction library is a task in itself. I don't have a personal preference but I'd like to use the one that is the most suitable for GNUnet. If I'm accepted, I think it'll be beneficial to do some experimentation and proof of concept work in the first couple of days to determine the decision.

Jeff, you mentioned the scheduler, would that this one ?

The application deadline is on the 25th. I will make the application today or tomorrow. If I run into any problems or have any questions I will ask them here.

Kind regards,

On 21 March 2016 23:33:50 CET, Jeff Burdges <address@hidden> wrote:
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 :

- Most examples by far. Okay docs :
- Nine contributors, quite active.
- Probably the most straightforward option, offers timers.
- There are some less developed coroutine libraries like

State Machine
- Best docs by far, including design blog, but fewer examples :
- 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.

- No docs, but eventual has docs :
- Three contributors, seven if you consider eventual. By mio guy
- Presumably similar to GNUNet's scheduler, except for possibly lacking
- Eventual looks like that abstraction about which Andrew spoke, but
overall probably too experimental.

- Some docs :
- Just one contributor. He works at
- Appears similar to GNUNet's scheduler, except for possibly lacking

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.


GNUnet-developers mailing list

Sent from my Android device with K-9 Mail. Please excuse my brevity.
reply via email to

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