> Example: We have process 10, which is a normal process. Like all
> processes, it has a manager thread with a TID equal to the PID.
> This process becomes multithreaded. We get something like this:
>
> /proc/10 original thread, now the manager. PID==TID
> /proc/13 thread 13 (system-wide numer) has PID 10 also
> /proc/42 another thread with PID 10
> /proc/78 another thread with PID 10
But not this.
What we want is, IM(ns)HO, this: /proc/10/0 (manager), /proc/10/[1-3]
(others), and _sym_links /proc/{13,42,78} pointing to /proc/10/[1-3].
(Simlinks so that it is visible that they are threads and not "real"
processes.) This calls a TID unique amongst a PID, not globaly unique.
Would that break existing semancits? (If so, change /proc/10/0 ->
/proc/10/10, /proc/10/[1-3] -> /proc/10/{13,42,78}.)
> Dave Wragg writes:
> > "Albert D. Cahalan" <acahalan@cs.uml.edu> writes:
> >> Dave Wragg writes:
>
> You planned to fix signal handling, right? With that and the stuff
> you already wrote, I'd say you have a working CLONE_PID. The current
> CLONE_PID looks like bad news for security and hasn't been useful.
> I would suggest that you just recycle the CLONE_PID name and bit.
NO! That's how you end up with unclean incompatablity. Scrap CLONE_PID,
make a new bit (CLONE_MINOR?). If sombody asks for CLONE_PID give them
existing behivor or dissalow it.
-=- James Mastros
-- True mastery is knowing enough to bullshit the rest. -=- Me- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu