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
https://gnunet.org/doxygen/d6/dcb/group__scheduler.html ?
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,
Kelong
On 21 March 2016 23:33:50 CET, Jeff Burdges <[email protected]> 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 :
>
>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
>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>GNUnet-developers mailing list
>[email protected]
>https://lists.gnu.org/mailman/listinfo/gnunet-developers
--
Sent from my Android device with K-9 Mail. Please excuse my brevity.
_______________________________________________
GNUnet-developers mailing list
[email protected]
https://lists.gnu.org/mailman/listinfo/gnunet-developers
