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

[Jeff Burdges]

On Tue, 2015-08-04 at 15:39 +0800, 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.

Great!  If we want more performance, then we can redo that part of your
library using mio, gj, etc., but no need to worry about that now.  

Also, it appears mio has abandoned plans to support Windows, saying
that's for a "higher level of abstraction" that currently nobody is
working on.  I'd imagine your code could run on Windows, so anyone try
to use mio does not need to feel guilty about abandoning them.  We'll
probably never care about that level of performance on Windows.  ;)

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

I know Rust abandoned libuv as too difficult to make safe bindings for,
ultimately resulting in mio.  I donno if that'd impact us in C.

> > 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'd think a safe wrapper can deal with that easily.

> I could call GNUNET_SCHEDULER_run then free task_cls and segfault. 

There are three ugly hacks that might work here :
- Give task_cls a 'static lifetime.  
- Create a fake variable with the lifetime task_cls needs.  And pass it
around to other GNUNet functions.  
- Leave specific functions as unsafe and make the developer read the
documentation to use them.  

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

Yeah, it sounds hard to verify that bindings are safe for only single
threaded operation, even if you find hacks to fix the most glaring
examples. 

Jeff

signature.asc
Description: This is a digitally signed message part