Re: pkg/54192: lang/rust build error

[Joerg Sonnenberger <joerg%bec.de@localhost>]

The following reply was made to PR toolchain/54192; it has been noted by GNATS.

From: Joerg Sonnenberger <joerg%bec.de@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: toolchain-manager%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
	netbsd-bugs%netbsd.org@localhost, ben@pocket.services
Subject: Re: pkg/54192: lang/rust build error
Date: Wed, 16 Oct 2019 17:14:56 +0200

 On Wed, Oct 16, 2019 at 02:10:02PM +0000, Kamil Rytarowski wrote:
 >  > Joergs patch makes the single lwp inherit the lid from the forking paren=
 >  > thread (instead of always being 1).
 >  
 >  This is right behavior of the kernel.
 
 You have given no justification for that.
 
 >  The same will happen on FreeBSD (lwpid is always unique globally), on
 >  Linux (getpid is always unique) etc.
 
 So our per-process LWP identifier should behave like global identifier
 from FreeBSD/Linux, because? They have little in common and the existing
 behavior is invalid even under the FreeBSD/Linux semantic.
 
 On a fundamental level, there are two sane models for a thread
 identifier:
 (1) It is globally unique.
 (2) It is process local and invariant.
 
 The current implementation in NetBSD fails both. A forked child of a
 multi-threaded program in a special intermediary state. It still shows
 various shadows of the other threads of the parent. Semantically again,
 there are two models to implement sensibly:
 (1) fork() creates a new thread, clones the address space and drops the
     thread from the parent. In this case, the thread identifier would be
     unique before the clone.
 (2) fork() clones the address space and preserves the nature of the
     current thread. In this case, the thread identifier should be
     preserved as is.
 Again, right now we do neither. The problem exists because the child
 overlaps the thread identifier of the parent, it re-uses a
 thread-identifier that should still be a in-use. The patch implements
 the second semantic. It makes _lwp_self() truely idempotent. Ensuring
 that it is not used at the time of fork in the parent would also be an
 option, but it is certainly more work and slower.
 
 Joerg