Date: Fri, 14 Jun 2024 12:52:53 +0100 From: David Chisnall <theraven@FreeBSD.org> To: Yuri <yuri@freebsd.org> Cc: Freebsd hackers list <freebsd-hackers@FreeBSD.org> Subject: Re: Can all environment be cached atomically? Message-ID: <635544F9-C62C-49B6-9BAC-104A34235BB3@FreeBSD.org> In-Reply-To: <4188f200-3923-43ed-b913-7358c4208522@FreeBSD.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] On 14 Jun 2024, at 11:26, Yuri <yuri@freebsd.org> wrote: > > Imagine the situation when a process has multiple threads which keep changing environment variables. I imagined it. It went like this: SIGSEGV It is undefined behaviour for two threads to change environment variables without explicit synchronisation of *all* readers and writers of environment variables. Any multithreaded program that calls `setenv` is almost certainly wrong. I would suggest that you follow these rules: - Never call setenv. If that can’t be done then: - Never call setenv in a shared library and - Never call setenv in a program after calling any function that *may* create threads. The first rule is easier to follow. There are *almost* not situations where calling `setenv` is the right thing to do. The only situation is where you should call it is to work around poorly designed shared libraries that provide no mechanism for communicating state to them other than environment variables. Then it’s not the right thing to do, it’s just the thing that you have to do to work around a bug. Environment variables exist to pass state from the environment into a newly created process. Any other use is likely to be a mistake. > Python's os.environ object is such environment cache, which is created when the Python interpreter is initialized. Almost certainly to avoid issues with concurrent writes from poorly written programs / libraries. David [-- Attachment #2 --] <html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">On 14 Jun 2024, at 11:26, Yuri <yuri@freebsd.org> wrote:<br><div><blockquote type="cite"><br class="Apple-interchange-newline"><div><div>Imagine the situation when a process has multiple threads which keep changing environment variables.<br></div></div></blockquote><div><br></div>I imagined it. It went like this:</div><div><br></div><div>SIGSEGV</div><div><br></div><div>It is undefined behaviour for two threads to change environment variables without explicit synchronisation of *all* readers and writers of environment variables. Any multithreaded program that calls `setenv` is almost certainly wrong. I would suggest that you follow these rules:</div><div><br></div><div> - Never call setenv. </div><div><br></div><div>If that can’t be done then:</div><div><br></div><div> - Never call setenv in a shared library and</div><div> - Never call setenv in a program after calling any function that *may* create threads.</div><div><br></div><div>The first rule is easier to follow.</div><div><br></div><div>There are *almost* not situations where calling `setenv` is the right thing to do. The only situation is where you should call it is to work around poorly designed shared libraries that provide no mechanism for communicating state to them other than environment variables. Then it’s not the right thing to do, it’s just the thing that you have to do to work around a bug.</div><div><br></div><div>Environment variables exist to pass state from the environment into a newly created process. Any other use is likely to be a mistake.</div><div><br></div><div><blockquote type="cite"> <span style="font-family: SourceCodePro-Regular;">Python's os.environ object is such environment cache, which is created when the Python interpreter is initialized.</span></blockquote></div><div><br></div><div>Almost certainly to avoid issues with concurrent writes from poorly written programs / libraries.</div><div><br></div><div>David</div><div><br></div></body></html>help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?635544F9-C62C-49B6-9BAC-104A34235BB3>