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 Fri, Nov 02, 2012 at 12:05:49AM +0530, Siddhesh Poyarekar wrote:
> 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.
Okay, you're absolutely right then. I had no idea __fork invoked
atfork handlers; I assumed it was like _Fork (which is to be added to
POSIX). I agree that part of the patch should be dropped.
Rich