Date: Thu, 22 Apr 1999 14:48:02 -0400 (EDT) From: Luoqi Chen <luoqi@watermarkgroup.com> To: peter.jeremy@auss2.alcatel.com.au Cc: hackers@FreeBSD.ORG Subject: Re: flock + kernel threads bug Message-ID: <199904221848.OAA06740@lor.watermarkgroup.com>
next in thread | raw e-mail | index | archive | help
> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199904221848.OAA06740>