An update on this : It appears gj has been split into a separate generic promises library gj and an IO library gjio : https://dwrensha.github.io/capnproto-rust/2016/04/24/gj-io-split.html
At first, that sounds great because we liked that separation in eventual, but he also dropped mio and does the system calls himself now: https://github.com/dwrensha/gj/commit/8fc9b2d301cf9c188221535d054c0b73c0ec4798 That makes me nervous, as mio solved thing gjio probably does not, but it's not a show stopper. We can still move from gj to eventual more easily than the reverse. Jeff On Thu, 2016-04-14 at 15:25 +0200, Jeff Burdges wrote: > 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. > > > _______________________________________________ > GNUnet-developers mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/gnunet-developers
signature.asc
Description: This is a digitally signed message part
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
