Re: [GNUnet-developers] Why old-school C?

[Christian Grothoff]

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.