[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Christian Grothoff
Subject: Re: [GNUnet-developers] Why old-school C?
Date: Tue, 04 Aug 2015 10:50:50 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.6.0

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.


>> 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:

I do not like this so much, as it focus on a poll()-style API and is not
really good for epoll()-style APIs:

> 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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]