Several versions back you added code that forces CLONE_PARENT behavior
whenever CLONE_THREAD is specified. This unnecesarily forces a particular
multi-threading model at the application level, and in fact breaks some
ways of doing multi-threading.
In particular, it requires that at least one task in an application *not*
be part of the thread group, and that the pid returned by the original
fork() can not be the thread group id itself.
It would still be entirely possible to code an application or threading
library in the way you envision by specifying CLONE_PARENT and CLONE_THREAD
together. However, there's no good reason for forcing this model.
A patch to remove that restriction is below.
Dave McCracken
======================================================================
Dave McCracken IBM Linux Base Kernel Team 1-512-838-3059
dmccr@us.ibm.com T/L 678-3059
----------
--- linux-2.4.13/kernel/fork.c Tue Oct 23 19:44:15 2001
+++ linux-2.4.13-signal/kernel/fork.c Wed Oct 24 11:46:09 2001
@@ -700,10 +721,10 @@
/* Need tasklist lock for parent etc handling! */
write_lock_irq(&tasklist_lock);
- /* CLONE_PARENT and CLONE_THREAD re-use the old parent */
+ /* CLONE_PARENT re-uses the old parent */
p->p_opptr = current->p_opptr;
p->p_pptr = current->p_pptr;
- if (!(clone_flags & (CLONE_PARENT | CLONE_THREAD))) {
+ if (!(clone_flags & CLONE_PARENT)) {
p->p_opptr = current;
if (!(p->ptrace & PT_PTRACED))
p->p_pptr = current;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Wed Oct 31 2001 - 21:00:22 EST