[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pkg/54192: lang/rust build error
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
(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.
Main Index |
Thread Index |