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

[Jeff Burdges]

First, I'm *not* the expert on asynchronous IO approaches here, so take
anything I say with a grain of salt.  Christian, Florian, etc. are the
ones who's opinions should carry weight.  I'm just prejudiced towards
anything that appears better at keeping me from shooting myself in the
foot.  :)  

Second, we should look into the examples for all these different mio
abstraction libraries.



On Mon, 2016-03-21 at 13:28 -0400, Andrew Cann wrote:
> How do you mean? Control-flow-wise your program looks exactly the
> same as if you were using blocking IO and threads.  Rust helps a
> lot in stopping you from being able to shoot yourself in the foot
> here: No piece of data can be accessed from multiple coroutines
> at once unless they all have read-only access.

I haven't looked into mioco well enough to comment really, maybe it
winds up very far from green threads, and not so far from promises in
practice, but..  

Rust only really provides memory safety, not say protection from
deadlocks due to an incorrect usage of Arc<Mutex<T>>. 

If you recreate threads, then you might be buying unneeded flexibility
by forgetting information you actually want. 


On Mon, 2016-03-21 at 13:18 -0400, Andrew Cann wrote:
> One problem with I have with all these options though is that
> they seem to force a particular paradigm on your entire program. 

I think that's kinda the point though.  Adhering to a more explicit
model *should* make the code easier to read and understand.  Assuming it
doesn't force you into doing something else in a convoluted way. 

> If you're writting an application that's fine, but gnunet-rs is
> a library and I'd like it if the users were free to write their
> gnunet application using state machines, green threads, blocking IO
> or whatever.

A priori, I'd imagine a GNUnet service would operate close to the
complete GNUnet packet level, although possibly able to start processing
an incomplete packet and pause for the rest.  And gnunet-rs would be
responsible for ensuring the entire packet got sent to the right place.
If you did this with green threads or coroutines, then you'd spawn a new
one for each packet, kinda recreating promises. 

> A vague solution that I'm imagining is if there was some way to
> write a low-level mio-based library in such a way that you could
> then use wrappers that take a generic low-level mio based library
> and promote it to a blocking IO based library, or a coroutine-based
> library or whatever. 

That is not a job for mio really.  An abstraction library like mioco
could provide traits to make it modular over your particular usage of
another abstraction, but maybe the impls would suck.

Jeff

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