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

[Andrew Cann]

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

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

> Care to elaborate about 'unsafe'?

If by 'unsafe' he means 'bug prone' then - by Rust standards - the whole GNUnet
API is unsafe. I could pass NULL pointers or non-NUL-terminated strings where
they're not expected and segfault. I could call GNUNET_SCHEDULER_run then free
task_cls and segfault. There's also thread-unsafe things all about the place
(convert_with_table using strtok and the execute-once guard in
gnsrecord.c:init() are two I've seen today). The rust compiler wouldn't let you
get away with any of this. Not being able to write bugs is really cool.

> In particular, I see that bratao seriously broke NAT (#3921, #3918), and
> that we have some fresh critical issues in CADET, CORE and DATASTORE in
> the bugtracker.  Shortening this list of typically rather trivial issues
> from key systems is likely a rather cost-effective method of attracting
> new users and developers ;-).  So I'll prioritize fixing those bugs over
> adding new features or rewriting stuff in new languages for now.

Definitely. The rust thing is fun but if anyone wants to help GNUnet they
should go work on the real implementation.

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.

 - Andrew

signature.asc
Description: Digital signature