Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

C stdlib isn't threadsafe and even safe Rust didn't save us

edgedb.com

Post reply on HN
Print view View original

271–280 of 370 posts

Re: C stdlib isn't threadsafe and even safe Rust didn't save us

#271

Post by bluGill »

api wrote: post #258
bluGill wrote: post #252

Earlier quoted context omitted.

There is a lot to like about the clould model as a user. I can access my data where ever I am, from what ever device I have, and I won't lose it to a disc crash. there are faults to the cloud but it solves real problems users have.

There are other ways that could be achieved, like cloud storage constantly mirroring local but encrypted with local keys or keys controlled by the user. This is the iCloud model and it works. Imagine a more open version with competing storage providers. This, however, would hand control back to the user, which would be bad for the software industry with its addiction to lock in and recurring revenue.

You also need the apps installed on whatever then, and enough CPU power to run those apps.

I'm not saying you are wrong, but there is a lot of nuance here.

Re: C stdlib isn't threadsafe and even safe Rust didn't save us

#272

Post by johnnyjeans »

api wrote: post #258
bluGill wrote: post #252

Earlier quoted context omitted.

There is a lot to like about the clould model as a user. I can access my data where ever I am, from what ever device I have, and I won't lose it to a disc crash. there are faults to the cloud but it solves real problems users have.

There are other ways that could be achieved, like cloud storage constantly mirroring local but encrypted with local keys or keys controlled by the user. This is the iCloud model and it works. Imagine a more open version with competing storage providers. This, however, would hand control back to the user, which would be bad for the software industry with its addiction to lock in and recurring revenue.

or plan 9

modern computing is mostly just the most malignant, worst possible re-interpretation of plan 9 anyways

Re: C stdlib isn't threadsafe and even safe Rust didn't save us

#273

Post by mad0 »

saagarjha wrote: post #210
vrtx0 wrote: post #201

Earlier quoted context omitted.

I provided a copy/paste from the site about the envp array size you asked about. I clarified why I mentioned fork(). I tried to explain the difference between registers and variables. I’m not trying to show off or bring anyone down… I just like to help people. I’m old (my first Linux kernel commit was in 2004). And I could be wrong — please LMK if I made a factual error (I’d appreciate it, honestly). All good?

I am going to do this once, but not again. Please pay attention to it. You are not just wrong, but failing to demonstrate an understanding of the actual topic being discussed. I can't say whether you actually have it or not, but your responses do not demonstrate this. I have dealt with plenty of people on this site who say things that are factually incorrect, many of whom have argued with me when I do so. You are not…

Sounds like you are arguing with a bot? em-dashes are a giveaway (nobody sane uses these "—")

Re: C stdlib isn't threadsafe and even safe Rust didn't save us

#274

Post by bandrami »

pshc wrote: post #92
usefulcat wrote: post #77

Earlier quoted context omitted.

But that won't actually fix the underlying problem, namely that getenv and setenv (or unsetenv, probably) cannot safely be called from different threads. It seems like the only reliable way to fix this is to change these functions so that they exclusively acquire a mutex.

The underlying problem is that setenv is mutable global state and should never have existed

I mean, it's only threadsafe in the sense that opening a file in cwd without being able to actually know what cwd is is "safe"

Re: C stdlib isn't threadsafe and even safe Rust didn't save us

#275

Post by kbolino »

nomel wrote: post #160
kbolino wrote: post #84

Earlier quoted context omitted.

Sure, there's a broader concept here, which doesn't require any operating system. But any alternate string->string map you define won't answer to C code calling getenv, won't be passed to child processes created with fork, won't be visible through /proc/$PID/environ, etc.

This is the context: > They did, it's called core. But it assumes no operating system at all, and environment variables require an operating system. I think there's some confusion here. The C standard library is an abstraction layer that exists to implement standard behavior on hardware. It's entirely unrelated to the existence of an OS. Things like "/proc/$PID/environ" have nothing to do with C. There are many stand…

I think newlib requires a discussion of its own, and more generally, the concept of a "full" libc outside of a formal operating system.

To put it bluntly, newlib is an antisocial libc. It provides bare compileability of programs by implementing C and POSIX facilities atop a small set of system calls. However, in practice, it requires basically nothing to actually work. If you look at what it requires [1], you can see that virtually all of the system calls are allowed to do nothing but return an error. The only function that is actually shown to do something is sbrk which is a simple bump allocator, and even then it's only strongly recommended to work so that malloc also works since a lot of ordinary C programs use malloc. This says to me "get code to compile at all costs" with no concern for a wider environment (since there may be no "wider environment" in the first place).

More charitably, we can view newlib as a set of compatibility shims bridging hosted and freestanding C. This has a place, of course; there are C libraries that assume a hosted implementation but don't really need (all of) a hosted implementation.

This doesn't really apply to nostd Rust, and creating a set of "environment variables" that interoperate with nothing, just because you can, is kind of pointless when there's no O/S and no FFI involved. I explained more about why (IMO) core::env/alloc::env shouldn't exist in the other comment.

All that having been said, newlib does seem to sit in a position somewhere between core+alloc and full std in terms of Rust (std also includes networking). Maybe there is a need for FFI/C compatibility without networking? I can't say for sure, but I haven't needed it.

[1]: https://sourceware.org/newlib/libc.html#Syscalls

Re: C stdlib isn't threadsafe and even safe Rust didn't save us

#276

Post by kibwen »

goeiedaggoeie wrote: post #230
usefulcat wrote: post #77

Earlier quoted context omitted.

But that won't actually fix the underlying problem, namely that getenv and setenv (or unsetenv, probably) cannot safely be called from different threads. It seems like the only reliable way to fix this is to change these functions so that they exclusively acquire a mutex.

setenv and getenv have never been thread safe, why the concern with it now?

The concern now is that, unlike when Posix was set in stone, threads exist.

Re: C stdlib isn't threadsafe and even safe Rust didn't save us

#277

Post by shortrounddev2 »

kelnos wrote: post #85

This reminded me of that whole "12-factor app" movement, which several of my former coworkers had really bought into. One of the "factors" is that apps should be configured by environment variables. I always thought this was kinda foolish: your configuration method is a flat-namespace basked of stringly-typed values. The perils of getenv()/setenv()/environ are also, I think, a great argument against using env vars fo…

I often find that there's a lot of intense animosity towards windows and Microsoft, but a lot of their API design is vindicated by time. Environment variables can be typed and templated in NT, not to mention there's a namespaced config database (the registry, even if it's really verbose and strange). Plus msvc provides threadsafe versions of nearly every stslib function. I often hear new C/C++ developers lament the lack of POSIX compatibility with MSVC, but without a lot of consideration for what that actually means; they just want cross compatibility with C programs written in the 1990s

Re: C stdlib isn't threadsafe and even safe Rust didn't save us

#278

Post by eadler »

GoblinSlayer wrote: post #206
saagarjha wrote: post #190

Earlier quoted context omitted.

A big reason to mutate argv is to change the process's name for tools like top.

For that you write to /proc/self/comm, that's where top gets it from.

This isn't true for the majority of operating systems.

Re: C stdlib isn't threadsafe and even safe Rust didn't save us

#279

Post by bluGill »

dietr1ch wrote: post #172
hinkley wrote: post #152

Earlier quoted context omitted.

I think there's a narrow window, at least in some programming languages, when environment variables can be set at the start of a process. But since it's global shared state, it needs to be write (0,1) and read many. No libraries should set them. No frameworks should set them, only application authors and it should be dead obvious to the entire team what the last responsible moment is to write an environment variable.…

Which programming languages? When using C++ I wanted programs to have a function that was called before main() and set up things that got sealed afterwards, like parsing command-line-arguments, the environment variables, loading runtime libraries, and maybe look at the local directory, but I'm not sure if it'll be a useful and meaningful distinction unless you restructure way too many things. I remember that on the F…

What is wrong with main setting those things first and then starting your main program? That is what everyone else does.

Re: C stdlib isn't threadsafe and even safe Rust didn't save us

#280

Post by janmatejka »

This reminds of the time I was not able to get setproctitle to work in certain code base. Eventually I narrowed the issue to this line:

  import numpy
setproctitle() worked before numpy import but not after because it couldn't find the memory address of **environ.

I'm hazy on the details but it led me to a somethingenv call (possibly getenv or setenv) in numpy initialization and it turned out that function changed the address of **environ and that was the reason for why setproctitle couldn't find it.

Post reply on HN