Christian has expressed an interest in GNUnet becoming modular over scheduler for asynchronous IO operations. There are two primary targets for this : - Qt's scheduler does not play well with others. We must support it for Qt applications. - The Rust community rejected all C schedulers as unsafe, or more precisely "slow if wrapped safely", so they wrote their own asynchronous IO stack.
We should imho target the Rust scheduler first because doing so will be more fun, so I'll talk about doing that. The question is : Where should we plug into their asynchronous IO stack? Including, where does their stack look most like GNUnet's existing asynchronous IO stack? In essence, the two choices is between living on top of tokio-core directly, or using the higher level abstractions in tokio-proto too. We'd use https://docs.rs/tokio-core/0.1.6/tokio_core/ for sure, but I do not know if we'd use https://docs.rs/tokio-proto/0.1.1/tokio_proto/ too. There is more documentation available at https://tokio.rs/docs/getting-started/tokio/ I'm not yet familiar with the recent changes to the GNUnet scheduler, but so far either choice looks doable really. Jeff p.s. Asynchronous IO stack components are mostly listed at https://tokio.rs/docs/going-deeper/third-party/ https://github.com/tokio-rs/ I skimmed their Cargo.toml files to get a rough idea of dependencies, so this list is generally ordered so that later depend on earlier. This looks like a lot of libraries, but many are small and/or nice abstractions that should compile down to nothing. Anything marked with a ? is something GNUnet overall needs, but Rust services should not need because another service like gnunet-arm or transport does everything we need. In particular, I think TLS and DNS might push us up the stack onto tokio-proto, but other GNUnet processes do everything we need there. futures-rs - Abstracts building state machines. http://alexcrichton.com/futures-rs/futures/ mio - Actually handles epoll/kqueue. And windows? https://carllerche.github.io/mio/mio/index.html tokio-io - Abstractions on top of futures-rs for reading and writing. https://tokio.rs/blog/tokio-io/ https://docs.rs/tokio-io/0.1.0/tokio_io/ tokio-core - This is where futures-rs and mio actually meet. https://docs.rs/tokio-core/0.1.6/tokio_core/ https://github.com/tokio-rs/tokio-core tokio-uds & mio-uds - Unix domain sockets !! https://github.com/tokio-rs/tokio-uds https://github.com/alexcrichton/mio-uds ? tokio-process & tokio-signal - Process management. https://github.com/alexcrichton/tokio-process https://github.com/alexcrichton/tokio-signal ? tokio-curl - Asynchronous interface to libcurl https://github.com/tokio-rs/tokio-curl tokio-timer - Timer functionality. https://github.com/tokio-rs/tokio-timer tokio-service - Abstractions on top of futures-rs for "services". https://docs.rs/tokio-service/0.1.0/tokio_service/trait.Service.html https://github.com/tokio-rs/service-fn tokio-middleware - Service-like interface for logging and timers. https://tokio-rs.github.io/tokio-middleware/tokio_middleware/ tokio-proto - This is where tokio-core and tokio-service meet. "a protocol is a way of providing or consuming a service". https://docs.rs/tokio-proto/0.1.1/tokio_proto/ https://github.com/tokio-rs/tokio-proto tokio-retry - asynchronous retry behaviors. https://docs.rs/tokio-retry ? tokio-tls - TLS, maybe a better choice will appear. https://github.com/tokio-rs/tokio-tls ? trust-dns - DNS resolution, maybe kinda heavy.
signature.asc
Description: This is a digitally signed message part
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
