From nobody Fri Jun 14 11:52:53 2024 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 4W0yMf286Cz5Nkm7 for ; Fri, 14 Jun 2024 11:53:02 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4W0yMf1gTZz4LDK; Fri, 14 Jun 2024 11:53:02 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1718365982; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=CZHSiHjZ9krsUrCWMuKk6wtiXeV8qW9ndxZuw3oLPGY=; b=xxmP3kYEy4ERHTBw+4RUAjlExV+L1MZw6e8Y6hWLsbcboHorFB/GRA461mXardP8RDvimH 8xJfm182KFvgFxDxsf3jx7kj7alHI7zxbTd0iEhZ33Cd1QoydX86kBRGVjYB71w2SK8DnZ KmcXZsm/vAQnAtI8DBmYnyRemR0zTwmx8rVKM+AowVUgEXElwUoKa92MIu+Io+BtXqHN0R aD6DGBCI1ncrnH3N4or28Pqct9fwg/F9EGuMh2TA7FUMle0MtOMnBsTrImGil/CvX7CDvo 8drv9Em2tYYta94PLLI6eHlO8wc5FXQqf9FSDLCX/iyMDbetbw/f1NA27UAPDA== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1718365982; a=rsa-sha256; cv=none; b=pR4Uy8VmR+72VhbcW2reALstTYe/WyYcMxHttjpI1xmCQcPpNPBlVjDuS+v4w+IsFDOMPr Rxehbnc7p80sbQhEjYMCW/kaUIcL0G4Avt+wvRgQozDXSware4305sk49QPrf2gLSxzdY6 qNHitPMAwcSEXE/Kq1K5BKYPOi/gWd1uF6XK/JQ1pe1vUFrFG8VeKjtx/ybrk8CppMzWWa qM2z5mSqyiP5lqlABk0lUUYagMhGANtCG09ebrPgRDKl+UcfTBrYfD7NhQ4ejB6/D0kecP 3Hybpz7S6Hy2tZxtamP+O/r8Z6bLHCi5LJOQ/LwFHg9sfUVeIXQfK6GZOP5ywg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1718365982; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=CZHSiHjZ9krsUrCWMuKk6wtiXeV8qW9ndxZuw3oLPGY=; b=Xb00702WEa44G4d0Dhm29c5ioGkpTLtaLgOG+xBGdiXDZQEvNE75n+sL0kXVc04yPiwp6x 19i59ZE2PxkMX2mv95OPSfCUkQmTH4QkX7PnKJKZyKyBap8XF1WroX5ZvdWwt2mmifcdLt lH2qb0lCUehcuzBlAIzifVzJ419UGsvoEAqrARwIXj2uF6LXn01+Nf0xN9pgbJWgb0P8O+ cUnEFFIDeKu0F9g/KrRIZRtl/8Jynz8TxnO2z3YyRm3So8ZNjxm/qjKtwgD3R336Jw5+DR KPULw9yqodhIujkvBI1crBpKzjHcodynYivMD+8Mqs7DKBJ2EnTU9Dvab/k+Jw== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id 4W0yMf1FNKz16xq; Fri, 14 Jun 2024 11:53:02 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtpclient.apple (host81-131-179-19.range81-131.btcentralplus.com [81.131.179.19]) by smtp.theravensnest.org (Postfix) with ESMTPSA id D179CB650; Fri, 14 Jun 2024 12:53:00 +0100 (BST) From: David Chisnall Message-Id: <635544F9-C62C-49B6-9BAC-104A34235BB3@FreeBSD.org> Content-Type: multipart/alternative; boundary="Apple-Mail=_3AF8F91B-C277-45BA-BE78-A9F933248DCD" List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@FreeBSD.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3774.600.62\)) Subject: Re: Can all environment be cached atomically? Date: Fri, 14 Jun 2024 12:52:53 +0100 In-Reply-To: <4188f200-3923-43ed-b913-7358c4208522@FreeBSD.org> Cc: Freebsd hackers list To: Yuri References: <4188f200-3923-43ed-b913-7358c4208522@FreeBSD.org> X-Mailer: Apple Mail (2.3774.600.62) --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 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 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=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--