Another option would be to use mioco. Mioco let's you write blocking/threaded style code but underneath uses green threads and non-blocking IO. This is similar to what you'd see in Go.
- Andrew On Mon, Mar 21, 2016 at 05:44:42PM +0100, Jeff Burdges wrote: > > We first need to get your application in to Google by whatever deadlines > they have. > > I'm seemingly listed as a mentor now and can see GNU applications when I > access their site at : https://summerofcode.withgoogle.com/dashboard/ > > If you go there, or to this google-melange.com site, can you see a way > to enter the application? If you need to identify me to them, my > account there is [email protected] I donno if we need to provide you > with something first though. > > > On Mon, 2016-03-21 at 15:03 +0100, kc wrote: > > > Thank you for the insight, no wonder I couldn't find any Rust code! > > > > I also feel starting with the second option is better since it has a > > mucher lower entry barrier so I can start hacking ASAP. > > > I see that GNS lookup, peer info listing and identity ego lookups are > > implemented. Do you think adding async IO to those functionalities by > > mid-term evaluation is feasible? What would you like to see by the end > > of the GSoC? Perhaps finish the "Next on the list" items? > > I think one reasonable goal might be : > > Use mio via rotor/eventual_io/gj to provide the asynchronous IO > functionality of GNUNet utils scheduler and adapt the peer info protocol > from gnunet-rs to use it. > > We can substitute peer info with whatever Christian thinks is the most > fundamental layer, but that's the one I'd expect. > > > I've used asyc IO in a few projects before. For instance I've > > goroutines/channels (from golang) to implement a few distributed > > algorithms such as for Byzantine agreement, leader election and mutual > > exclusion. I also used some of the Haskell async libraries > > namely Control.Concurrent for a project where we had to implement the > > log-structured merge-tree. Finally, I've used pthreads when I was > > working on an enterprise backup system. I don't have any async IO > > experience in Rust but the paradigms shouldn't be to different. > > Ok great. > > > Regarding those libraries, I can't say I'm familair with the state > > machine based ones like rotor. On the other hand, I'm familair with the > > concept behind Futures and Promises which is what gj and eventual_io > > uses. Is there a preferred async IO model for GNUnet-rs or it's still > > up for discussion? > > I've little opinion myself. I'd just like it to be easier to read than > the current GNUnet utils stuff. I think that'll be the case with any of > gj, eventual_io, or rotor. > > I think the question is really : What model do you like? And do you > have any opinions about what fits best with what situations? I'll look > closer at the options and ask Christian for his opinion though too. > > Jeff > >
signature.asc
Description: Digital signature
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
