[HN Gopher] Improving Steam Client Stability on Linux
       ___________________________________________________________________
        
       Improving Steam Client Stability on Linux
        
       Author : Venn1
       Score  : 29 points
       Date   : 2024-11-11 21:41 UTC (1 hours ago)
        
 (HTM) web link (ttimo.typepad.com)
 (TXT) w3m dump (ttimo.typepad.com)
        
       | bhaney wrote:
       | > If this can be addressed in glibc, it may involve a tradeoff on
       | features, maybe an opt-in mechanism with a slight departure from
       | the "impossible" POSIX spec. That's something we may pursue in
       | the long term if we can propose something sensible.
       | 
       | Yes please
        
       | jeffbee wrote:
       | Maybe among the best decisions Java ever made was hiding setenv.
       | You simply cannot set env vars in Java.
        
       | o11c wrote:
       | The real question is: is there _any_ case where a program calls
       | `setenv` in one thread and actually _wants_ it to take effect in
       | other already-existing threads?
       | 
       | That said, GLIBC _is_ pretty good at documenting all the
       | dangerous functions, so it is _possible_ to add locking /copying
       | yourself.
        
       | fweimer wrote:
       | We've got patches under review:
       | https://inbox.sourceware.org/libc-alpha/cover.1722193092.git...
       | (triggered by https://issues.redhat.com/browse/RHEL-42410, a
       | graphics stack stability issue that wasn't as visible in RHEL 9
       | for some reason)
       | 
       | At least the first one (the getenv thread safety fix) will
       | hopefully make it into glibc 2.41 and it should be quite safe to
       | backport. It turns out that setenv is easier to handle because
       | glibc already never frees environment strings. It's concurrent
       | unsetenv that is rather tricky. Without some snapshot approach,
       | getenv would return null pointers instead of environment
       | variables values that are actually set. I don't want to introduce
       | locking into getenv because getenv without setenv has been async-
       | signal-safe for so long that it would likely break applications.
       | 
       | The environ handling fixes are a bit more controversial because
       | vfork+execve make it complicated to avoid memory leaks, but are
       | less important to the stability of the graphics stack.
        
       ___________________________________________________________________
       (page generated 2024-11-11 23:00 UTC)