Date: Thu, 22 Apr 1999 14:10:31 -0500 From: "Richard Seaman, Jr." <dick@tar.com> To: Luoqi Chen <luoqi@watermarkgroup.com> Cc: peter.jeremy@auss2.alcatel.com.au, hackers@FreeBSD.ORG Subject: Re: flock + kernel threads bug Message-ID: <19990422141030.A484@tar.com> In-Reply-To: <199904221848.OAA06740@lor.watermarkgroup.com>; from Luoqi Chen on Thu, Apr 22, 1999 at 02:48:02PM -0400 References: <199904221848.OAA06740@lor.watermarkgroup.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Apr 22, 1999 at 02:48:02PM -0400, Luoqi Chen wrote: > > 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. Maybe. But, if you want POSIX compliant pthreads, you need to be able to send a signal to a thread (pthread_kill()), as well as to the process (kill()). Also, you need to be able to set the priority of a thread (pthread_setschedparam()) as well a the priority of the process (setpriority() or sched_setscheduler(), etc). The pthread functions take a pthread_t parameter to identify the threads. If the threads are kernel threads, how do you communicate to the kernel which thread you're acting on if the threads are "anonymous" in userland? > Inside the kernel, the threads or processes are still named by their > (struct proc *) pointer, so there won't be any confusion. -- Richard Seaman, Jr. email: dick@tar.com 5182 N. Maple Lane phone: 414-367-5450 Chenequa WI 53058 fax: 414-367-5852 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?19990422141030.A484>