Re: pkg/54192: lang/rust build error

[Kamil Rytarowski <n54%gmx.com@localhost>]

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

From: Kamil Rytarowski <n54%gmx.com@localhost>
To: Martin Husemann <martin%duskware.de@localhost>, Joerg Sonnenberger <joerg%bec.de@localhost>
Cc: gnats-bugs%netbsd.org@localhost, 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 20:38:49 +0200

 On 16.10.2019 17:25, Joerg Sonnenberger wrote:
  >
  >   So our per-process LWP identifier should behave like global identifie=
 r
  >   from FreeBSD/Linux, because? They have little in common and the
 existing
  >   behavior is invalid even under the FreeBSD/Linux semantic.
 
 This was just an example that thread id is not preserved across forks.
 
 It's the same in NetBSD (but sometimes it can be by an accident preserved)=
 .
 
 
 On 16.10.2019 17:29, Martin Husemann wrote:
 > On Wed, Oct 16, 2019 at 05:14:56PM +0200, Joerg Sonnenberger wrote:
 >> 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.
 >
 > Agreed so far, but the question is whether "invariant" holds across fork=
 ().
 >
 
 After fork(2) we have a new process entity and the LWP ID is local to
 new thread.
 
 > Pragmatically we should look for the easiest solution.
 >
 
 However... this behavior proposed by Joerg is still conformant with POSIX.
 
 "A process shall be created with a single thread. If a multi-threaded
 process calls fork(), the new process shall contain a replica of the
 calling thread and its entire address space, possibly including the
 states of mutexes and other resources. [...]
 "
 
 https://pubs.opengroup.org/onlinepubs/9699919799/functions/fork.html
 
 So, let's go with it.
 
 > Martin
 >
 >