[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[GNUnet-developers] GNUnet and multi-threading
From: |
Andrew Cann |
Subject: |
[GNUnet-developers] GNUnet and multi-threading |
Date: |
Wed, 22 Oct 2014 19:50:57 +0800 |
User-agent: |
Mutt/1.5.21 (2010-09-15) |
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] GNUnet and multi-threading,
Andrew Cann <=