Over the last couple of days I've been writing a rust library for GNUnet. Rust libraries are supposed to use a mult-threaded-with-blocking-calls api design but I couldn't find a way to build this around the C library's single-threaded-event-loop-with-callbacks design. So I ended up avoiding GNUnet's scheduler entirely which meant re-writing all of the socket-level stuff. What would be better though - and would make it possible to build a blocking api - is if it were possible to run the scheduler in a seperate thread. This would mean calling GNUNET_SCHEDULER_run in it's own thread and then calling the other api functions like (for example) GNUNET_GNS_lookup from the program's main thread and expecting the callback to be called from the scheduler thread. Finally you'd need to be able to shutdown the scheduler by calling GNUNET_SCHEDULER_shutdown from outside the scheduler thread. None of this should be too hard to implement. It would just mean putting a lock on the scheduler and on all of the GNUNET_<SERVICE>_Handle objects. You'd also need a way to wake up the scheduler but you could do that by having it always select() on a pipe that you write to to wake it up.
Would people be interested in me implementing this or should I stick to re-writing parts of the api in Rust? - Andrew _______________________________________________ GNUnet-developers mailing list GNUnet-developers@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers
