Review request for 5049299
roland at redhat.com
Tue Jun 30 02:28:22 UTC 2009
> But...posix_spawn doesn't give you any way to delete *all* file descriptors
> and if you try to collect them before spawning, there is a race in a
> multithreaded program.
This is something you should never want to do. There is notoriously no
good way to do it on some systems, where getdtablesize() can return
RLIM_INFINITY and is not proper to use in a loop.
Use FD_CLOEXEC when you open the descriptor in the first place.
> (Aside: I also wonder why glibc's implementation of posix_spawn avoids
> using vfork if there are file actions specified)
Hmm, I'm not sure about that. I also have no idea why you aren't asking
these questions on the libc-alpha mailing list.
> Linux clone has avoided vfork's bad press, and has occasionally been
> described as "elegant". For a while I believed that clone() was the only
> system call that created new processes, and that vfork() was just an
> inflexible special case of clone(), and on ia64 that appears to be true,
> but on x86 clone(), fork() and vfork() are separate system calls,
> and glibc has different gobs of assembly code around each.
Internally it's true. On some machines there are separate vfork and/or
fork calls, some not. If you are worried about what the semantics mean,
it is immaterial which system call number you used and how many arguments
you passed. It's all the same "clone" code in the kernel.
More information about the core-libs-dev