Valve dev details more on the work behind making Steam for Linux more stable

Steam Game Recording was recently released, which came as part of a big Stable Steam Client update that noted it had fixes for "miscellaneous common crashes" on Linux. Now we know a little more on what's happening behind the scenes.

Coming from a blog post from developer Timothée Besset, who does a lot of Valve work, Besset mentions how a change to how they approach the setenv and getenv functions that made the "most significant impact to Steam client stability on Linux".

For some context:

• setenv: change or add an environment variable.
• getenv: get an environment variable.

According to Besset, one of their colleagues claimed setenv as "the worst Linux API", even though it's such a common API available across all platforms "it was a little difficult to convince ourselves just how bad it is" — ouch. And they already knew, at least on Linux, that "setenv and getenv aren't safe to use in multithreaded environments".

Pictured - Steam Client

Part of their problem though is how on Linux you have so many distributions with different window managers, desktop environments, driver versions, extensive user customization and so on. So their own crash reports end up "very noisy". Another issue is that setenv will at times in a multithreaded program "crash outright", on top of that they found that "other threads would blow up though, usually with a SIGABRT, shortly after calling getenv", and their backtraces for the crashes were "all over the place and could not be easily tied to a single cause".

So what did they do? Here's what:

• We removed the majority of setenv calls. It was mostly used when spawning processes, and refactoring to use exevpe to pass down a prepared environment is an all around improvement.
• We reduced how much we rely on getenv, mostly by caching the calls. There is still an uncomfortable amount of it, but it's in OS libraries at this point (x11, xcb, dbus etc.) and we continue reducing it's usage.
• For the few remaining setenv use cases that could not be easily refactored, we introduced an 'environment manager' that pre-allocates large enough value buffers at startup for fixed environment variable names, before any threading has started.

It's a fun little read worth a couple minutes of your time if you're interested on behind the scenes info, and how at times building for Linux can be a minefield.

According to a comment on the post, these issues are in fact being worked on in glibc, so it may not be such a problem in future for Linux developers.

The more stable it is, the better the experience will be for people switching to Linux, and of course for the Steam Deck too since SteamOS is Linux. Nice to see Valve developers constantly trying to make everything better.