From owner-freebsd-hackers Wed Apr 21 21: 6:30 1999 Delivered-To: freebsd-hackers@freebsd.org Received: from alcanet.com.au (border.alcanet.com.au [203.62.196.10]) by hub.freebsd.org (Postfix) with ESMTP id 1F7A9158D2 for ; Wed, 21 Apr 1999 21:05:57 -0700 (PDT) (envelope-from peter.jeremy@auss2.alcatel.com.au) Received: by border.alcanet.com.au id <40369>; Thu, 22 Apr 1999 13:49:28 +1000 Date: Thu, 22 Apr 1999 14:03:10 +1000 From: Peter Jeremy Subject: Re: flock + kernel threads bug To: luoqi@watermarkgroup.com Cc: hackers@FreeBSD.ORG Message-Id: <99Apr22.134928est.40369@border.alcanet.com.au> Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG Luoqi Chen wrote: >This is a different (bigger) problem, i.e. pid sharing among threads, >it is also desirable for signal handling. I doubt that which id is stored in >the lock really matters, and this issue will go away as soon as we solve >the bigger pid sharing problem. 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 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message