Messages in this thread | | | From | cd_smith@ou ... | Date | Thu, 15 Jul 1999 09:24:06 -0500 (CDT) | Subject | Re: linux-kernel-digest V1 #4144 |
| |
Darren Reed <avalon@coombs.anu.edu.au> > p.s. one person I've spoken to claimed that the Linux clone implementation > breaks some aspect of signal handling/delivery but that may just as well be > rhumour.
This is as good a time as any, I suppose, to advertise the patch I'm working on and ask for suggestions on the approach.
I'm working on fixing quite a few of these problems right now -- started with the signals problem, but since my signal fixes will make a proper /proc implementation easy I will do that as well. Basically, the problem (for those of you who aren't familiar) is that POSIX says a signal sent to a process will be handled by any thread that doesn't have it blocked. Currently, since different threads have different PID's, a signal sent to a process is implicitly directed at a specific thread -- if that thread blocks the signal, then POSIX semantics are broken.
My fix is to add a 'struct process_struct' (not to be confused with the similarly named thing that got renamed to struct task_struct) which is reused when CLONE_PID is specified. I will add another hash table of pid -> process_struct, and when a signal is sent to a process, I look up the process rather than task, and then find a task belonging to that process that isn't blocking the signal, and deliver the signal to that task. I'd also have to add a new syscall for pthread_kill to work properly.
I am also planning on fixing /proc with CLONE_PID by making procfs scan the process list rather than the task list, and only add one directory entry per process. Tasks can then be represented as a subdirectory within a process directory... and for backwards compatibility I suppose I'll grab the rest of proc information from the first task and put it in the base process directory. Since most proc-based info is cloned anyway for threads, this means that a non-thread-aware ps will work properly in "most" situations. A thread-aware ps can ignore the backward compatibility issues and look at the properties of each individual "thread" (which is really more than a thread because it has the flexibility to have its own address space, etc.) Some time (Linux 5.0 or something like that) we can remove the "backwards compatible" files like, say, /proc/101/mem, since different tasks in process 101 can really have different address spaces... ps should use /proc/101/1/mem instead (to get the address space of thread id 1 in process 101).
I think the above fixes some problems without losing the flexibility of cloning over LWPs.
Any comments or objections to this approach.
Chris Smith <cd_smith@ou.edu>
PS: Any other problems to fix with CLONE_PID? I tried searching linux-kernel, and only found a mention of the duplicate proc directories problem.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |