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> References: <4188f200-3923-43ed-b913-7358c4208522@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--Apple-Mail=_3AF8F91B-C277-45BA-BE78-A9F933248DCD Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 On 14 Jun 2024, at 11:26, Yuri <yuri@freebsd.org> wrote: >=20 > 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. =20 If that can=E2=80=99t 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=E2=80=99s not the right thing to do, it=E2=80=99s 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 --Apple-Mail=_3AF8F91B-C277-45BA-BE78-A9F933248DCD Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 <html><head><meta http-equiv=3D"content-type" content=3D"text/html; = charset=3Dutf-8"></head><body style=3D"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=3D"cite"><br class=3D"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=E2=80=99t 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=E2=80=99s not the right = thing to do, it=E2=80=99s 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=3D"cite"> <span = style=3D"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></htm= l>= --Apple-Mail=_3AF8F91B-C277-45BA-BE78-A9F933248DCD--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?635544F9-C62C-49B6-9BAC-104A34235BB3>