Re: [GNUnet-developers] [GSoC] Question on "Rust implementation of GNUnet utils" project

[Jeff Burdges]

On Mon, 2016-04-25 at 00:06 +0200, Kelong Cong wrote:
> - Is it confirmed that we'll use gj going forward?

Appears not.  :)  I just had a very useful conversation with Florian who
knows way more about this than I. 


As a first task, we should worry about doing the GNUnet style wire
formats nicely, including endiannes.  It appears gnunet-rs does not do
this so well right now, so maybe much needs to change. 

I think our first task here is to figure out Rust's version of
__attribute__((packed)) for structs in GCC 4s, known as #pragma
pack(push,1) and #pragma pack(pop) elsewhere.  I think repr(C) and
repr(packed) together work : 
  https://doc.rust-lang.org/nomicon/other-reprs.html
Just fyi, the introduction to the Rustonomicon is cute : 
  https://doc.rust-lang.org/nomicon/README.html
There are more details here : 
  https://github.com/rust-lang/rfcs/blob/master/text/1399-repr-pack.md

It's worth noting that "Taking a reference into a struct marked
repr(packed) [is] unsafe" and cannot store Drop types :
https://github.com/rust-lang/rfcs/blob/master/text/1240-repr-packed-unsafe-ref.md
As an aside, it's nice to clone a copy of
https://github.com/rust-lang/rfcs to grep for shit like this.

Also, the C type unions that just landed in Rust nightly* might help :
  https://github.com/rust-lang/rfcs/blob/master/text/1444-union.md
ref. https://github.com/rust-lang/rust/issues/32836
     https://github.com/rust-lang/rfcs/pull/1444

I'm not 100% sure how we expose these structs to Rust, maybe they should
be copied into normal Rust structs without unsafe fields, but that keep
around the original and "move" any large aligned fields, and replacing
any unions with Rust style tagged unions similarly.

Anyways, it's definitely our first priority to get this wire format
stuff cleaned up nicely, maybe even "lightly script" the conversion.


After that, we should try to emulate the GNUnet utils APIs relatively
closely.  I based my preference for promises/futures on my small amount
of playing around inside GNUnet utils where all callbacks are single
use, but Florian says the higher level stuff uses other patterns. 

We should still consider following this two-crate API and implementation
model used by eventual and gj however, possibly even forking one of
those to add what we need, but our prority should besticking close to
the GNUnet utils API. 

As an aside, the only really intentionally multi-pattern thing I know is
ZeroMQ, and I've heard their docs are ell written, so I'll try to skim
that soonish : 
  http://zguide.zeromq.org/page:all
  http://curvezmq.org/page:read-the-docs

Also, Florian stressed that systems built on promises/futures do not
necessarily support cancellation well.  We've a long sorted history with
cancellation apparently, so it's good to get that sorted out form the
beginning. 


Finally, Florian singled out the statistics service as being rather
simple but using many different asynchronous IO patterns, so doing
bindings for that gives us a concrete goal that'll help us sort out the
wider API correctly.


Sound good?

Jeff


* I'm against trying to stick to stable Rust because too much important
stuff depends on nightly, including mio.

signature.asc
Description: This is a digitally signed message part