在 Steam 最近改善穩定性之後，Linux 社群掀起了關於多執行緒應用程式中環境變數處理的熱烈討論。雖然 Steam 的臨時解決方案解決了其特定問題，但 GLIBC 開發團隊似乎正在推出一個更全面的解決方案。
GLIBC 即將推出的執行緒安全改進
GLIBC 開發者正在積極開發補丁，以解決環境變數長期存在的執行緒安全問題。根據社群討論，這些改進計劃在 GLIBC 2.41 中實現，其中 getenv 的執行緒安全修復被列為優先事項。這些變更特別重要，因為它們解決了影響多個應用程式（包括圖形棧元件）的穩定性問題。
環境變數處理的現狀
Linux 中的環境變數 API 實現一直是開發者面臨的重大挑戰。雖然 Windows 和 macOS 提供了執行緒安全的實現，但 Linux 的方法一直存在問題。macOS 選擇了洩漏字串而不是崩潰的方案，而 Linux 應用程式則不得不實施各種變通方法。這導致不同專案採用了創新性的解決方案，一些開發者建議採用基於連結串列的方法來提高執行緒安全性。
Java 的保守方法
關於環境變數處理，社群中出現了一個有趣的觀點，即 Java 的處理方式。Java 語言設計者有意禁止直接修改環境變數，考慮到其他平臺面臨的挑戰，現在一些開發者認為這是一個有先見之明的決定。儘管這種限制可能使某些任務變得更復雜，但它避免了困擾其他環境的執行緒安全問題。
你可以為你啟動的程序傳遞一個新的環境，這我認為是足夠的？你只是不能修改現有程序的環境。
未來影響
GLIBC 提出的改變代表著一個重要的進步，儘管實現完整的執行緒安全仍面臨挑戰，特別是在處理 unsetenv 等函式時。開發團隊正在仔細考慮向後相容性問題，因為沒有 setenv 的 getenv 歷來是非同步訊號安全的，破壞這種行為可能會影響現有應用程式。
這項持續的工作展示了在維護現有軟體相容性的同時改進系統穩定性和安全性之間的複雜平衡。隨著這些變更的推進，不僅 Steam ，整個 Linux 生態系統都可能從中受益。
來源引用：Improving Steam Client stability on Linux: setenv and multithreaded environments