I've learned slightly more about our asynchronous IO options. I'll give some notes below, but the short version is :
We should *first* trying using gj for a Rust implementation of GNUnet utils because it's actually the most restrictive callback-like event loop. It'll be easier to migrate from gj to anything else. Jeff Notes : There are interesting features of both eventual_io vs gj : - Eventual provides the abstraction layer that Christian and Andrew expressed an interest in. - Cap'n proto has an interesting RPC facility built on gj. And they differ with how they interact with threads : - Eventual imposes Send bounds frequently, so that types can move between threads. As it better abstracts thread pools, but you must use Arc<> types lots. - Anywhere that eventual needs an Arc<>, gj uses its non Send cousin an Rc<>. It follows gj cannot interact as flexibly with threads, but really Rc<> should be viewed as "more thread safe" because you're forbidden from sharing them between threads at all. In particular, it's easier to migrate code based on gj over to eventual that the reverse. It's easier to make eventual code run on top of another thing, like say a state machine, but that's unlikely. And porting gj code to eventual code appears really trivial if one wishes to do is that way. And gj's restrictions would help if making the transition more manually. We should hold off starting the Cap'n proto RPC conversation since it does not pertain to existing GNUnet services, but it add extremely interesting long-term options. There is a good chance Rust gains higher-kinded types within the next couple years, which should enable eventual to be polymorphic over bounds, and might precipitate a merger of eventual and gj. > 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 > Promises > https://github.com/dwrensha/gj > - Some docs : http://docs.capnproto-rust.org/gj/index.html > - Just one contributor. He works at Sandstorm.io We should probably avoid coroutines, meaning no mioco, since we should not need that messy extra flexibility for GNUnet's proposes. Also, Christian expressed reservations about building on APIs significantly more powerful than necessary. > Coroutines > https://github.com/dpc/mioco > - Most examples by far. Okay docs : > http://dpc.pw/mioco/mioco/index.html > - Nine contributors, quite active. There are folks singing the praises of state machines, like https://engineering.shopify.com/17488160-why-developers-should-be-force-fed-state-machines And they do have greater advantages in Rust, like helping eliminate even Rc<> wrappers. I suspect however that our code in GNUnet is largely higher level than where they really shine. > 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.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
