Weird

Posted Aug 17, 2016 23:40 UTC (Wed) by lsl (subscriber, #86508)
In reply to: Weird by Cyberax
Parent article: Better types in C using sparse and smatch

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