Re: [GNUnet-developers] GNUnet and multi-threading

[Christian Grothoff]

I agree with LRN on the point that I would not want to see changes to
the C library to enable threads for the scheduler.  As for writing a
blocking multi-threaded replacement for Rust, I'm not sure how good that
idea is from a software engineering point of view. Sure, it may be more
in line with language paradigms and may in some cases be easier to
debug, but overall having to worry about locking and data races in a
large code base is worth quite a bit.  GNUnet had threads until 0.8, and
they caused much, much pain.  I somehow doubt that Rust magically makes
all of those problems go away.  Still, if you think that you really need
a blocking API for Rust, go ahead, but please don't expect the C code to
adapt for it.  As LRN said, there would be many issues with the code
once additional threads are introduced.

On 10/22/14 14:16, LRN wrote:
> On 22.10.2014 15:50, Andrew Cann wrote:
>> 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. 
> 
>> Would people be interested in me implementing this or should I stick to
>> re-writing parts of the api in Rust?
> 
> IMO, rewrite.
> 
> GNUnet scheduler and event loop with callbacks are a necessary evil: GNUnet
> avoids multithreading in C, and this is the only way to do it (that i know 
> of).
> Any operations that could take any considerable amount of time are broken up
> into multiple procedures chained together by the scheduler. This complicates
> debugging and makes the code more difficult to read. Don't drag this into 
> Rust,
> use tasks for such things.
> 
> You may or may not need some kind of event dispatcher loop (possibly multiple
> loops?), but it will just spawn tasks to handle stuff, at most. Hopefully. I
> don't grok Rust well enough to just make up a working model for a GNUnet
> service written in Rust in my head without running it past the compiler to see
> if it relies on something unsafe.
> 
> Also, interfacing with GNUnet C libraries basically makes your program unsafe:
> you call a C library that has very weak safety guarantees (and could have even
> more threading-related issues hidden by the fact that GNUnet avoids
> multithreading) instead of using the "unsafe" keyword to isolate small pieces
> of code where you, personally, can enforce safety (as it's too complex for the
> compiler to handle).
> 
> Do spend a few months (years?) re-writing parts of libgnunetutil in Rust on 
> top
> of Rust stdlib. That's better than spending decades catching bugs and arguing
> with the GNUnet C implementation devs about the interface they present in the
> libraries and how it could be made more Rust-friendly.
> 
> You'll probably be able to re-use parts of the util librariy related to
> crypto/hashes.
> 
> 
> 
> _______________________________________________
> GNUnet-developers mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnunet-developers
>