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
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
