Re: pkg/54192: lang/rust build error

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

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