From owner-freebsd-hackers  Thu Apr 22 11:51: 0 1999
Delivered-To: freebsd-hackers@freebsd.org
Received: from lor.watermarkgroup.com (lor.watermarkgroup.com [207.202.73.33])
	by hub.freebsd.org (Postfix) with ESMTP id 354C314A12
	for <hackers@FreeBSD.ORG>; Thu, 22 Apr 1999 11:50:32 -0700 (PDT)
	(envelope-from luoqi@watermarkgroup.com)
Received: (from luoqi@localhost)
	by lor.watermarkgroup.com (8.8.8/8.8.8) id OAA06740;
	Thu, 22 Apr 1999 14:48:02 -0400 (EDT)
	(envelope-from luoqi)
Date: Thu, 22 Apr 1999 14:48:02 -0400 (EDT)
From: Luoqi Chen <luoqi@watermarkgroup.com>
Message-Id: <199904221848.OAA06740@lor.watermarkgroup.com>
To: peter.jeremy@auss2.alcatel.com.au
Subject: Re: flock + kernel threads bug
Cc: hackers@FreeBSD.ORG
Sender: owner-freebsd-hackers@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> How about the following (off the top of my head so it may not be
> feasible):
> 
> The underlying problem is that POSIX requires each thread to have the
> same PID whereas rfork gives each thread a different PID.  How about
> adding a new `thread group' (similar to a process group) to a process.
> 
> Normally, fork() would make the thread group the same as the PID.  A
> flag to rfork() would allow the child process to inherit the thread
> group (and probably parent pid) from its parent instead.  If I
> understand POSIX correctly, signal semantics would need to be altered
> to send signals to the thread group, rather than a process id.
> 
> Two new system calls would be required to allow a process (rather than
> a thread group) to be killed, as well as obtain the thread group.
> 
> As a further naming change, `process ID' could be changed to `thread
> ID', allowing `thread group' to be renamed `process ID'.  This may
> make the terminology clearer to multi-threaded processes outside the
> kernel.
> 
> Peter
> 
I've been thinking about a more drastic one, store the same PID in the
threads' proc structure. PID is no more than a name of a process in the
userland, and in userland we see all the threads as the same process.
I don't think we really need a thread id, the threads are anonymous.
Inside the kernel, the threads or processes are still named by their
(struct proc *) pointer, so there won't be any confusion.

-lq


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message