Re: proc fs and shared pids
Aaron Ucko (joot@vnet.ibm.com)
Tue, 6 Aug 1996 12:00:41 -0400 (EDT)
> There isn't. We discussed this some time ago (I don't remember with whom),
> and it was felt to be generally a "good thing". It has the advantage of
> allowing normal UNIX utilities to automatically work both on the whole
> "process" (in the traditional thread meaning) while still allowing the same
> utilities to handle individual threads if they wanted to.
>
> Traditional threads suck. The whole idea with the Linux "clone()" was to look
> at the thread idea from a new perspective, and have something that makes the
> difference between threads and processes fade away. We want to have threaded
> programs, but we ALSO want to not think of the threads as anything special:
> they are just another form of processes. As such I don't want special thread
> system calls, instead I want _generic_ system calls that work both in a
> thread and a process context. That's why I proposed the high-bits thread-ID
> approach.
>
> The only problem as far as I'm concerned is that I don't actually use the
> thread facilities, and as such I'm unlikely to start coding. I've been hoping
> that people that are interested in threads start using clone() for them
> (which finally has happened, thank God), and that as it becomes clear that we
> need more support (like the thread ID thing) people start sending me patches.
> Hint hint..
After playing around with the Xavier's clone() based pthreads package,
for which the threads use different pids I made some small kernel
modifications to put the thread information in the high bits of the
pid as you suggested earlier.
Basically the "tid" is the position of the task_struct in the task array --
I thought this would be a simple and quick way to get a unique thread
identifier since it is found anyways in the do_fork().
I can send or post a patch, but I wanted to test it out a bit more first.
Peeter
--
Peeter Joot TOROLAB(PJOOT) joot@vnet.ibm.com
IBM Canada Tie Line 778-3186 Phone 416-448-3186