On 08/04/2015 09:39 AM, Andrew Cann wrote: >> Just some thoughts on doing GNUNet code in Rust ... > > For the GNUnet rust library that I've been writing I avoid GNUNET_SCHEDULER > and > callbacks entirely and use threads and blocking calls instead. It's the more > "rusty" way of doing things (as rust makes threading safe). The downside is it > means reimplementing GNUnet's IPC protocols.
Yep. >> 2) There isn't just libevent and libev. There's also libuv and glib, and >> then a bunch more that are (probably?) less well-known. > > Thoughts on libuv? It seems to be what everyone is using these days. It has a > BSD-style license though. Alternatively we could make an effort to port libev > to windows then use that instead. See below: I'm for being ultra-generic, not picking one particular event loop. The main reason is simple: there will be apps out there using libevent, libev, libuv, glib and event loops we don't even know about. When they want to integrate with GNUnet C APIs, we right now effectively require them to switch to GNUNET_SCHEDULER. That's impractical and horrible (bad us). Us switching to something else is not the solution: it may help one app, but will equally break stuff for another. So being generic is the only good solution. >> 3) But really, the answer is entirely different: what we need is a >> *pluggable* event loop, just like the glib event loop is pluggable. > > Interesting. So what would that look like? I imagine you'd have a > GNUNET_EventLoop object that you pass to the GNUNET_*_connect functions to > use. > You could create one by calling a GNUNET_EVENTLOOP_default() to spin up > GNUNET_SCHEDULER or libev or whatever but you could also create one from > callbacks with something like > > GNUNET_EVENTLOOP_create( > callback_for_adding_a_file_descriptor_to_poll, > callback_for_removing_a_file_descriptor) > > You could then implement your own callback_for_... to tie it into libuv or > whatever. Is that the basic idea? Yes. Additional inspiration: https://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.html#GPollFD I do not like this so much, as it focus on a poll()-style API and is not really good for epoll()-style APIs: https://developer.gnome.org/glib/stable/glib-The-Main-Event-Loop.html#GPollFunc > Speaking of which... Christian, I've applied to do a Master's of informatics > at > TUM. If I get accepted do you think it would be possible to transfer to Rennes > 1 for second year and start working at Inria? Also, do you have any idea how > long TUM usually take to process applications? I'm pretty worried that they > haven't accepted or rejected me yet and semester starts 1st of October. I have no clue about TUM, Sree or Matthias might be in a position to inquire. As for moving to Inria after a year, that's (1) a lot of moving and (2) would be subject to availability of funds on my side, which I cannot say much about this far in advance. So my advice would be to first plan to stay 2 years in Munich, but once you're actually there we can still always see how the situation develops. _______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
