On Wed, 2017-03-22 at 00:12 +0100, lurchi wrote: > I'm planning to write a secushare API in Rust which uses the > Future/Stream types from the futures crate in combination with a Core > event loop (tokio_core crate). > We are using Qt, too through the Rust bindings from https://github.com/ > White-Oak/qml-rust, so integrating Qt's event loop with GNUnet is not > our goal right now. In the end it should be possible to integrate any > event loop with GNUnet of course.
I suppose qml-rust runs Qt in a separate thread. > Did I understand it correctly that modifying the GNUnet scheduler means > you're planning to not do IPC with the GNUnet services from Rust > anymore? That would be good news to me because it's easier to maintain > the Rust bindings when they call the API functions (which are supposed > to change rarely). No. Ain't necessarily so easy to analyze the memory safety of any given C API that uses the GNUnet scheduler. This might remain problematic even if the GNUnet scheduler were running on top of mio, tokio, etc. > I was playing around a bit with the GNUnet scheduler already to open it > up to other event loops (see the attached patch). It's a quick try and > probably needs to be improved. Basically I introduced two new API > functions: > > - GNUNET_SCHEDULER_set_work_callback: allows setting a callback which > is called after select returned. The callback is expected to schedule a > task in the external event loop. After that the GNUnet event loop > blocks > > - GNUNET_SCHEDULER_do_work: the scheduled task is expected to run this > function, so all the available GNUnet tasks can be executed. After that > GNUnet's event loop continues to run Sounds interesting. I'm happy to look deeper into it. > When it comes to how to schedule a task in the tokio_core event loop, I > was thinking of a 'Stream' (https://docs.rs/futures/0.1.11/futures/stre > am/trait.Stream.html) which is spawned before the GNUnet scheduler is > started. Communication with that stream should be possible with the > task::park and task::unpark (see https://docs.rs/futures/0.1.11/futures > /task/fn.park.html). > > This is my first idea and it's possible that I overlooked something, > the tokio.rs stuff is not the easiest to see through. I've no idea right now. :) > I'm confused. Why would GNUnet need tokio-tls or trust-dns? I took the long way of saying it does not. Jeff
signature.asc
Description: This is a digitally signed message part
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
