gnunet-developers
[Top][All Lists]
Advanced

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

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


From: LRN
Subject: Re: [GNUnet-developers] GNUnet and multi-threading
Date: Wed, 22 Oct 2014 16:16:22 +0400
User-agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:35.0) Gecko/20100101 Thunderbird/35.0a1

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.

-- 
O< ascii ribbon - stop html email! - www.asciiribbon.org

Attachment: 0x922360B0.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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