This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] BZ #14782 system async cancellation
On Thu, 1 Nov 2012 13:57:32 -0400, Rich wrote:
> Where? The existence of FORK as a way to provide an alternate for
> __fork is not any inherent problem anyway; the problem (which isn't
> really a problem anyway, just gratuitous code complexity) is just the
> use of clone with special flags in place of fork on Linux.
All the system.c files in sysdep (barring sysdeps/posix/system.c of
course) are of the form:
#define FORK....
#include <sysdep/unix/sysv/linux/system.c>
so that they define FORK as a direct shortcut to clone. Definitions
are present in s390, sparc and ia64 and not just in
sysdep/unix/sysv/linux/system.c and they override the one you removed.
I didn't give it much thought earlier, but why do you want to replace
the direct clone syscall with the slow path of __fork? __fork will do
everything from executing atfork handlers to (re)setting mutexes -
unnecessary work when we're simply going to exec next.
It might make sense to just drop that part of your patch and have it
stick to removing the cancellation enabling/disabling code.
Siddhesh