Messages in this thread | | | Date | Thu, 25 Jun 1998 14:19:48 -0400 | From | James Michael Mastros <> | Subject | Re: Thread implementations... |
| |
On Thu, Jun 25, 1998 at 09:47:38 AM -0400, Albert D. Cahalan wrote: > It is better to avoid that, because it is unnecessarily complicated. > The existing CLONE_PID is simply bad. The concept isn't bad. > Solution: /proc has numeric directories, named by _thread_ ID. Hmm... I'd agree with this...
> 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
| |