Date: Thu, 22 Apr 1999 14:03:10 +1000 From: Peter Jeremy <peter.jeremy@auss2.alcatel.com.au> To: luoqi@watermarkgroup.com Cc: hackers@FreeBSD.ORG Subject: Re: flock + kernel threads bug Message-ID: <99Apr22.134928est.40369@border.alcanet.com.au>
next in thread | raw e-mail | index | archive | help
Luoqi Chen <luoqi@watermarkgroup.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?99Apr22.134928est.40369>