[ ... ]
> Under '/proc/pid' would be the 'normaly' files that contain the
> task info, and a sub-directory for each thread in the task.
>
>
> OK, I've missed a lot out, but this is the basic idea.
> Comments?
>
>
> markhe
>
This sounds exactly like processes and process groups, with the added
kink that the processes can share memory.
Let me give an example for my case. Suppose I want to write an X program
which does some lengthy computation, and I decide to have one thread
do the calculation while a second thread draws intermediate results in
a window. Here are two options I have under Linux 2.0:
1) Use clone() to create the threads, and communicate via
shared memory.
2) Use fork() to create the "threads", and communicate via
pipes.
>From the kernel's perspective these two have some significant
differences, but from the perspective of userspace each just looks a
pair of cooperating processes. In neither case would you want to throw
a signal to just one of the two "threads"; you should send it to both
of them and let them divvie it up however seems reasonable.
I guess basically what I'm saying is, if we just rename the term "process
ID" to "thread ID", don't we have already the functionality we want,
without confusing old software that doesn't know about threads.
Hmm, just came to mind: in any case, allowing multiple processes sharing
the same pid is not currently fully functional (note the sebject of the
thread!); shouldn't this option be dissalowed until 2.1?
Lex