Hacker News Reader

Comment by roblabla | Hacker News Reader

My first thought when reading this is "what about rust" ? Rust uses the system libc to support most of it's standard library, so could it have the same problem ?

A quick look at the std::env::set_env docs [0] tells us that Rust is aware the underlying implementation are inherently thread-unsafe, and looking at its implementation [1] tells us that rust uses a global lock for all access to the environment.

So at least, it will avoid segfaulting your programs.

Good job rust :D

EDIT: However, I guess if you fork() (which is not something you can do with the standard rust library AFAIK, so requires unsafe), you may get the first problem of having a deadlock.

[0]: https://doc.rust-lang.org/std/env/fn.set_var.html

[1]: https://github.com/rust-lang/rust/blob/51d29343c04a27570a8ff...

View on HN

If your fork in a multithreaded program, you have bigger problems. You can deadlock taking any lock in the child that could possibly have been taken by some thread at the time of fork. In practice, you can't predict all these locks, so the only sane thing you can do in a forked child of a multithreaded program is call async-signal-safe functions (as POSIX commandeth) and probably execve something.

You could also invalidate all locks from the parent with some kind of generational scheme based on pid or whatever. I believe the Python interpreters do something crazy like this to try and avoid deadlock after forking multithreaded programs.

So what? Under that scheme, you can take the locks, but the lock-protected data structures are probably garbage. (That is, the locks become implicitly "abandoned", not "unlocked".)

I'm not defending it as a model. I think python's approach to fork & thread interaction, which is to punt on it completely while exposing both to end users, is pretty broken.

> However, I guess if you fork() (which is not something you can do with the standard rust library AFAIK, so requires unsafe)

https://github.com/rust-lang/rust/blob/0c85f2a1bdb01666e74cd...

Command::spawn() calls fork(). And you can schedule things to run on the child with CommandExt::before_exec().

before_exec is unstable AFAIK ?

EDIT: To be stabilized in 1.15 coming in two days.

Oh well, at least, it shouldn't be possible to invoke UB. Hopefully :D

That's an unfortunate implementation. posix_spawn() is much faster in large applications because it doesn't need to make all MAP_PRIVATE mappings read-only for CoW purposes.

Rust could hand-roll it by calling clone() directly, but the code is a bit tricky.

> So at least, it will avoid segfaulting your programs.

That's implying there are no setenv() calls in the C code that the Rust code calls.

Why does everything related to C have to have comments on rust ?

Because the point of Rust is to be a better C.

So? That doesn't mean every submitted article mentioning C or C++ has to immediately be filled with comments on how Rust is so much better, safer, etc - So is Java and C#, and you don't see those communities espousing their language the same way!

Because Java and C# are not system programming languages and are not intended to replace C?

Would I want my init system written in Java or C#? Hell no. Would I want it written in Rust? Yes please maybe it will crash less and have fewer CVEs.

I have a belief that every time a C developer switches to Rust, users benefit (unless developer goes crazy from Rust's cognitive load, but this is a separate issue :) )

If you ask me rust is also not for programming systems. (the error handling specifically)

Side note: Who even started the whole "x is a system programming language" ? Who said you can't write "system software"[0] in just about any language that can (directly or indirectly) do "lower level" things. For example the MS Singularity OS has a virtual machine and all the drivers and everything is high level code.

>Would I want my init system written in Java or C#? Hell no. Would I want it written in Rust? Yes please maybe it will crash less and have fewer CVEs.

Contrary to popular belief init systems are simple and can be written in any language. Not to mention that when people talk about inits they don't think about the actual initialization part (mounting, setting network, etc) but about the starting of programs part. Those two things are similar from a far but are really not so much.

>I have a belief that every time a C developer switches to Rust, users benefit (unless developer goes crazy from Rust's cognitive load, but this is a separate issue :) )

I have a belief that people should make up their own mind and do whatever they want. This topic is about C and only about C. All other talk is "noise".

Note that i actually like programming in C as i like optimized programs, so i may be biased. (although not nearly as biased as the rust crowd)

[0] https://en.wikipedia.org/wiki/System_programming_language

> This topic is about C and only about C. All other talk is "noise".

Why do you get to decide? There are a lot of people in this thread talking about similar issues in other languages (Python, Rust, etc) and other functions (like fopen() and exit()). I think those discussions are very on-topic.

Why isn't this topic about "issues between threads and setenv in any language that uses glibc"?

Why isn't this topic about "issues between threads and other functions in any language that uses glibc"?

If you don't like a particular conversation in this topic, you can collapse it and move on.

From one (or more) of the comments here you can see that the reasoning for rust in topics about C is "everybody should write rust instead of C". At least for some people.

One other comment got it right, it is annoying to have multiple rust comments in every thread about C.

But you are right, best way to deal with these kinds of... i don't want to be rude, is ignoring.

PS Thank you for addressing the rest of the comment, not just the part you made personal.

In some things it is, while in some things it ain't. In some things haskell is better then bout, in some things it ain't. In fact the same could be said about most programming languages.

But that is not the point...

Rust marketing.

Because it's HN and there is a segment of the population here who feel compelled to promote the New Shiny any chance they get, irrespective of how terrible it looks, or how badly it squanders their credibility.

In this case, for example, the underlying issue (as usual) isn't "C language BAD!" it's that the function call isn't thread-safe. Which can happen in any language, including Rust.

I'm not an expert, but I thought safe rust had guaranteed thread safety?

https://doc.rust-lang.org/book/concurrency.html

"Thread safety" is more than just protection against data races, which (AFAIK--I am quite happy to acknowledge being wrong here) is the guarantee Rust makes.

Part of the issue with that slogan is that "thread safety" doesn't have any specific definition. Yes, we're specifically talking about data races, as well as the general Send/Sync bounds, but for a blurb on the home page, "thread safety" is the best thing we could come up with. Pitches need to be succinct and get the idea across, but due to the succinctness, can't capture 100% of the details.

No doubt, and I wasn't intending to ding the docs. Rust docs are a paradigm to be emulated in almost every case in my opinion.

None taken! This issue has come up on HN before, just trying to clarify and support what you were saying.

Uh, the question was not actually about languages, but about use of glibc.

You can have a C that doesn't use glibc and doesn't have this problem. The question here is whether Rust, which in using the system libc will often use glibc on linux systems, has a way of working around this problem elegantly.

Yes, mentioning Rust on every C/C++ is fairly annoying...

glibc is a library that is used by countless programming languages. The question of "how do languages with a focus on safety deal with the unsafety of glibc" is a perfectly valid question.

I think it's a natural comparison to expect, since Rust aims to fix many of C/C++ shortcomings.

BTW Jorge Aparicio is working on a std that doesn't need a libc [1], at least for those supported platforms.

[1] https://github.com/japaric/steed

Reply on news.ycombinator.com