lkml.org 
[lkml]   [1996]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: proc fs and shared pids


On Tue, 6 Aug 1996, Albert Cahalan wrote:
>
> eiserloh@llab.chinalake.navy.mil (Peter P. Eiserloh) writes:
>
> > All threads within a process have the same pid (no ifs and or buts).
> > Threads are identified with their own identifier (tid).
>
> A user should see this as pid.tid for running shell commands.

Nope. Do you want to make Linux-specific version of all the shells, utilities
etc? "kill" is a built-in in most shells, perl etc..

The good thing about putting the tid in the high bits is that you can use
_unmodified_ generic UNIX utilities that do not know threads from a hole in
the ground. You can write a "perl" script that does thread-aware things (the
perl script _itself_ wouldn't be threaded, but the perl programmer could make
it be the front-end to a threaded program, for example). Or think of a Tcl/Tk
program where the Tcl/Tk scripts are just a front-end to a threaded process..
You want that Tcl/Tk program to signal individual threads (let's say there is
one thread for user interface stuff, for example), but you do NOT want to
modify the Tcl/Tk interpreter itself.

You might use something like "pid.tid" as a _shorthand_ in specific tools
(instead of using a unwieldly 32-bit pid that is hard to remember), but as
it's not generic it should be considered the secondary interface at most.

Linus


\
 
 \ /
  Last update: 2005-03-22 13:38    [W:0.073 / U:2.396 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site