Weird

Posted Aug 15, 2016 19:39 UTC (Mon) by halla (subscriber, #14185)
In reply to: Weird by excors
Parent article: Better types in C using sparse and smatch

This post really helps sell Rust to me... My particular problem is that I maintain a million-line application written in C++ that consists of a dozen or two libraries, a hundred or so plugins, and those libraries use C++ or C libraries. I would like to experiment with rewriting the most core libr ary in something like Rust, but that still means that that library needs to:

a) use a C library
b) handle file io and other standard stuff
c) provide a base for the C++ libraries to build onto
d) make it possible to write plugins in C++ or Python that this core library can load

I'm sure the a) and b) are provided for -- but I cannot figure out whether c) and d) are possible.

Weird

Posted Aug 15, 2016 19:49 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link] (12 responses)

Rust can interface with C easily and there are code generators to create automatic bindings for C libraries.

Rust also is really easy to expose to C or C++, it doesn't have any runtime with garbage collector or static initializers that live before main(). You really can treat it as a safe version of C.

Of course, translating a huge codebase is not going to be easy. To get advantage of Rust you really need to encode Rust's notion of ownership into the interface with C/C++ and that's not always trivial.

Weird

Posted Aug 15, 2016 19:56 UTC (Mon) by halla (subscriber, #14185) [Link] (2 responses)

Yes, indeed -- that's why I would like to start with one library, and maybe even just do a Qt-based inteface wrapper around that. We've always kept our code split up nicely, so it should be possible. And I'm so sick and tired of ambiguous ownership...

Weird

Posted Aug 16, 2016 3:12 UTC (Tue) by ncm (guest, #165) [Link] (1 responses)

The best choice of library to first code in Rust, to get immediate reward for the effort, is one that processes untrusted input -- decrypting, rendering, decrypting, deserializing, taking remote commands. Such plugins account for a majority of vulnerabilities in Firefox. Of course you still have to fuzz them, but failures are much easier to account for when you know they haven't corrupted random memory, and success is easier to trust.

Weird

Posted Aug 19, 2016 15:15 UTC (Fri) by ncm (guest, #165) [Link]

Sorry, that was supposed to be "decrypting, rendering, decompressing, deserializing... ".

Weird

Posted Aug 17, 2016 22:46 UTC (Wed) by lsl (subscriber, #86508) [Link] (8 responses)

> Rust also is really easy to expose to C or C++, it doesn't have any runtime with garbage collector or static initializers that live before main(). You really can treat it as a safe version of C.

Not quite, as you must not fork a program linked to Rust code. You only get a spawn-like interface where the runtime takes care to safely fork the program, followed by an immediate call to exec (just like with Go).

Did this really change recently? Not long ago, the Rust developers' position was something along the lines of "fork won't ever be safe to do in Rust".

Weird

Posted Aug 17, 2016 23:06 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (7 responses)

You can fork as much as you want with Rust. It doesn't create any threads behind the scenes.

Of course, if you use TLS or create threads yourself then you're on your own.

Weird

Posted Aug 17, 2016 23:40 UTC (Wed) by lsl (subscriber, #86508) [Link] (6 responses)

Only if you forego using any standard library code. If you want to fork, the stdlib is verboten.

Weird

Posted Aug 17, 2016 23:54 UTC (Wed) by Cyberax (✭ supporter ✭, #52523) [Link] (3 responses)

Standard library code is not dependent on any runtime except for jemalloc ( https://doc.rust-lang.org/book/custom-allocators.html ). There is no "life before main()" of any kind and the runtime doesn't store any state at all if you disable unwinding.

Weird

Posted Aug 18, 2016 2:02 UTC (Thu) by lsl (subscriber, #86508) [Link] (2 responses)

Yet, standard library usage in forking programs seems to be considered undefined behaviour, including the loss of all memory-safety guarantees. You're supposed to use #![no_std] and libcore only. The reason seems to be that libstd code might kick off threads (IO-related modules?) or get its RNG state duplicated on fork or a host of other things.

So while the new Rust with mostly-excised runtime itself might be used in forking programs, touching the standard library is still considered to result in nasal demons by its developers.

Weird

Posted Aug 18, 2016 3:32 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

> Yet, standard library usage in forking programs seems to be considered undefined behaviour, including the loss of all memory-safety guarantees.
Really? How? Borrow checker is entirely compile time and after forking the new copy will go on independently.

Standard library does NOT run any background threads and RNG duplication might be an expected outcome.

I can't find any recent admonitions to not use libstd in forking programs and having actually used it, I kinda doubt that there are any serious issues.

Weird

Posted Aug 23, 2016 20:43 UTC (Tue) by mathstuf (subscriber, #69389) [Link]

Do you have links to back this up? It seems odd that there'd be a `std::process` module in the standard library[1] if using it with the standard library causes problems (at least without some kind of documentation).

[1]https://doc.rust-lang.org/nightly/std/process/index.html

Weird

Posted Aug 18, 2016 8:55 UTC (Thu) by farnz (subscriber, #17727) [Link] (1 responses)

I can't find any such limitation in versions of Rust post the decision to not use a green-threading model. In prerelease versions, the userspace thread manager could get confused by fork(), but the thread manager has gone away.

Weird

Posted Aug 18, 2016 9:46 UTC (Thu) by micka (subscriber, #38720) [Link]

All I found myself was this issue:
https://github.com/rust-lang/rust/issues/16799

Especially from comment
https://github.com/rust-lang/rust/issues/16799#issuecomme...

which states (if I understand correctly) that it was unsafe to fork when rust used a runtime, but when the runtime was removed, the only problem left was the hashmap implementation using a rng with a shared seed (the rng being used to prevent DOS by hashmap collision).