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
[email protected] 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;
On 20011024 Dave McCracken wrote:
>
>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.
>
Will this break current pthreads in glibc 2.2.4 ???
--
J.A. Magallon # Let the source be with you...
mailto:[email protected]
Mandrake Linux release 8.2 (Cooker) for i586
Linux werewolf 2.4.13-beo #2 SMP Thu Oct 25 00:59:08 CEST 2001 i686
--On Thursday, October 25, 2001 02:10:21 +0200 "J . A . Magallon"
<[email protected]> wrote:
> Will this break current pthreads in glibc 2.2.4 ???
No, the pthread library that comes with glibc doesn't use CLONE_THREAD.
Dave McCracken
======================================================================
Dave McCracken IBM Linux Base Kernel Team 1-512-838-3059
[email protected] T/L 678-3059