|
Home > Archive > Unix Programming > January 2004 > Linux glibc clone(2) vs fork(2)
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Linux glibc clone(2) vs fork(2)
|
|
| Michael B Allen 2004-01-23, 5:10 pm |
| What is the glibc clone(2) equivalent of fork(2)? The prototype is:
#include <sched.h>
int clone(int (*fn)(void *), void *child_stack, int flags, void *arg);
If I simply replace:
if (fork() == 0) {
fn(fn_arg);
exit(0);
}
with:
clone(fn, malloc(0xFFFF), SIGCHLD, fn_arg);
I do not get the same behavior. I'm in the process of tracking down
exactly what *is* different now but I'd really appreciate it if someone
would clue me in.
Thanks,
Mike
| |
| Paul Pluzhnikov 2004-01-23, 5:10 pm |
| Michael B Allen <mba2000@ioplex.com> writes:
quote:
> What is the glibc clone(2) equivalent of fork(2)?
There isn't one.
quote:
> clone(fn, malloc(0xFFFF), SIGCHLD, fn_arg);
> I do not get the same behavior.
Nor should you. For one thing, stack on Linux grows in *the other* direction.
Now, if you really really want to do the above (WARNING: there is
really no sane justification for doing this), try:
clone(fn, (char *)malloc(0x10000) + 0xFFFC, CLONE_FILES | CLONE_SIGHAND, fn_arg);
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
| |
| Paul Pluzhnikov 2004-01-23, 5:10 pm |
| Michael B Allen <mba2000@ioplex.com> writes:
quote:
> What is the glibc clone(2) equivalent of fork(2)?
There isn't one.
quote:
> clone(fn, malloc(0xFFFF), SIGCHLD, fn_arg);
> I do not get the same behavior.
Nor should you. For one thing, stack on Linux grows in *the other* direction.
Now, if you really really want to do the above (WARNING: there is
really no sane justification for doing this), try:
clone(fn, (char *)malloc(0x10000) + 0xFFFC, CLONE_FILES | CLONE_SIGHAND, fn_arg);
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.
| |
| Michael B Allen 2004-01-23, 5:10 pm |
| On Mon, 22 Dec 2003 19:34:13 -0500, Paul Pluzhnikov wrote:
quote:
> Michael B Allen <mba2000@ioplex.com> writes:
>
>
> There isn't one.
>
>
> Nor should you. For one thing, stack on Linux grows in *the other*
> direction.
>
> Now, if you really really want to do the above (WARNING: there is really
> no sane justification for doing this), try:
>
> clone(fn, (char *)malloc(0x10000) + 0xFFFC, CLONE_FILES |
> CLONE_SIGHAND, fn_arg);
That worked. Thanks.
Yes, I know this is not supposed to be used directly but I'm at a point
in my server implementation where I can see everything I've coded so far
work if I can just share the file table. With this little change indeed
it all works. Flawlessly to my surprise! I've taken my measurements (22%
drop in performance over threads). Now I need to implement descriptor
passing ...
I'm curious though; will this support changing security contexts or
locales and so on? I'm creating a "multiple processes accessing all data
in shared memory coordiated with System V semaphores" model. Eventually
I want to be able to service clients with worker procs that can setuid,
setlocale, etc based on handler requirements. Is this do-able with this
CLONE_FILES thing or is it no better than threads in this respect?
Do you know of other operating systems that support sharing the file
descriptor table? If descriptor passing turns out to be a big drop in
performance it might be worth it to be able to take advantage of this
feature if the system supports it. It also introduces some interesting
security possibilities like getting the stacks from non-PROT_EXEC mmap'd
memory.
Mike
| |
| Michael B Allen 2004-01-23, 5:10 pm |
| On Tue, 23 Dec 2003 02:54:35 -0500, Michael B Allen wrote:
quote:
> it all works. Flawlessly to my surprise! I've taken my measurements (22%
> drop in performance over threads).
Mmm, no. It's actually an 11% *increase* in performance with processes
vs threads. Wierd.
Mike
| |
| Michael B Allen 2004-01-23, 5:10 pm |
| On Mon, 22 Dec 2003 19:34:13 -0500, Paul Pluzhnikov wrote:
quote:
> Michael B Allen <mba2000@ioplex.com> writes:
>
>
> There isn't one.
>
>
> Nor should you. For one thing, stack on Linux grows in *the other*
> direction.
>
> Now, if you really really want to do the above (WARNING: there is really
> no sane justification for doing this), try:
>
> clone(fn, (char *)malloc(0x10000) + 0xFFFC, CLONE_FILES |
> CLONE_SIGHAND, fn_arg);
That worked. Thanks.
Yes, I know this is not supposed to be used directly but I'm at a point
in my server implementation where I can see everything I've coded so far
work if I can just share the file table. With this little change indeed
it all works. Flawlessly to my surprise! I've taken my measurements (22%
drop in performance over threads). Now I need to implement descriptor
passing ...
I'm curious though; will this support changing security contexts or
locales and so on? I'm creating a "multiple processes accessing all data
in shared memory coordiated with System V semaphores" model. Eventually
I want to be able to service clients with worker procs that can setuid,
setlocale, etc based on handler requirements. Is this do-able with this
CLONE_FILES thing or is it no better than threads in this respect?
Do you know of other operating systems that support sharing the file
descriptor table? If descriptor passing turns out to be a big drop in
performance it might be worth it to be able to take advantage of this
feature if the system supports it. It also introduces some interesting
security possibilities like getting the stacks from non-PROT_EXEC mmap'd
memory.
Mike
| |
| Michael B Allen 2004-01-23, 5:10 pm |
| On Tue, 23 Dec 2003 02:54:35 -0500, Michael B Allen wrote:
quote:
> it all works. Flawlessly to my surprise! I've taken my measurements (22%
> drop in performance over threads).
Mmm, no. It's actually an 11% *increase* in performance with processes
vs threads. Wierd.
Mike
|
|
|
|
|