Separate CLONE_PARENT and CLONE_THREAD behavior

PATCH In review Dave McCracken 2 participants 3 messages Oct 24, 2001 – Oct 25, 2001

Subsystems (3)

MM core Scheduler exec and binfmt

lore

Share & tools

lore

Dave McCracken

author

2001-10-24 19:16 UTC #0 lore raw

PATCH 1/1 Separate CLONE_PARENT and CLONE_THREAD behavior

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

----------

kernel/fork.c +2 -2

@@ -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;

J . A . Magallon

2001-10-25 00:10 UTC #1 lore raw

Quoted 10 lines · 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.

Quoted 6 lines

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 ???

Signature · 4 lines

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

Dave McCracken

author

2001-10-25 13:24 UTC #2 lore raw

--On Thursday, October 25, 2001 02:10:21 +0200 "J . A . Magallon"

Quoted 1 line · <[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