One use of these systems calls is to implement threads: multiple
flows of control in a program that run concurrently in a shared
address space.
Note that the glibc clone() wrapper function makes some changes
in the memory pointed to by stack (changes required to set the
stack up correctly for the child) before invoking the clone()
system call. So, in cases where clone() is used to recursively
create children, do not use the buffer employed for the parent's
stack as the stack of the child.
The kcmp(2) system call can be used to test whether two processes
share various resources such as a file descriptor table, System V
semaphore undo operations, or a virtual address space.
Handlers registered using pthread_atfork(3) are not executed
during a clone call.
In the Linux 2.4.x series, CLONE_THREAD generally does not make
the parent of the new thread the same as the parent of the
calling process. However, for kernel versions 2.4.7 to 2.4.18
the CLONE_THREAD flag implied the CLONE_PARENT flag (as in Linux
2.6.0 and later).
On i386, clone() should not be called through vsyscall, but
directly through int $0x80.
C library/kernel differences
The raw clone() system call corresponds more closely to fork(2)
in that execution in the child continues from the point of the
call. As such, the fn and arg arguments of the clone() wrapper
function are omitted.
In contrast to the glibc wrapper, the raw clone() system call
accepts NULL as a stack argument (and clone3() likewise allows
cl_args.stack to be NULL). In this case, the child uses a
duplicate of the parent's stack. (Copy-on-write semantics ensure
that the child gets separate copies of stack pages when either
process modifies the stack.) In this case, for correct
operation, the CLONE_VM option should not be specified. (If the
child shares the parent's memory because of the use of the
CLONE_VM flag, then no copy-on-write duplication occurs and chaos
is likely to result.)
The order of the arguments also differs in the raw system call,
and there are variations in the arguments across architectures,
as detailed in the following paragraphs.
The raw system call interface on x86-64 and some other
architectures (including sh, tile, and alpha) is:
long clone(unsigned long flags, void *stack,
int *parent_tid, int *child_tid,
unsigned long tls);
On x86-32, and several other common architectures (including
score, ARM, ARM 64, PA-RISC, arc, Power PC, xtensa, and MIPS),
the order of the last two arguments is reversed:
long clone(unsigned long flags, void *stack,
int *parent_tid, unsigned long tls,
int *child_tid);
On the cris and s390 architectures, the order of the first two
arguments is reversed:
long clone(void *stack, unsigned long flags,
int *parent_tid, int *child_tid,
unsigned long tls);
On the microblaze architecture, an additional argument is
supplied:
long clone(unsigned long flags, void *stack,
int stack_size, /* Size of stack */
int *parent_tid, int *child_tid,
unsigned long tls);
blackfin, m68k, and sparc
The argument-passing conventions on blackfin, m68k, and sparc are
different from the descriptions above. For details, see the
kernel (and glibc) source.
ia64
On ia64, a different interface is used:
int __clone2(int (*fn)(void *),
void *stack_base, size_t stack_size,
int flags, void *arg, ...
/* pid_t *parent_tid, struct user_desc *tls,
pid_t *child_tid */ );
The prototype shown above is for the glibc wrapper function; for
the system call itself, the prototype can be described as follows
(it is identical to the clone() prototype on microblaze):
long clone2(unsigned long flags, void *stack_base,
int stack_size, /* Size of stack */
int *parent_tid, int *child_tid,
unsigned long tls);
__clone2() operates in the same way as clone(), except that
stack_base points to the lowest address of the child's stack
area, and stack_size specifies the size of the stack pointed to
by stack_base.
Linux 2.4 and earlier
In Linux 2.4 and earlier, clone() does not take arguments
parent_tid, tls, and child_tid.
