This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Caching of PID/TID after fork
>> Though, one useful feature which could be potentially useful for some
>> porjects would be to create a detached process (for which the kernel
>> doesn't send termination signal - usually SIGCHLD - to the parent
>> process). And this cannot be solved by ORing custom flags with fork
>> ones, because SIGCHLD is already there. But, it's just a guess.
>
> Yes, I know of some cases where this would have helped as well.
>
> If we go the fork-with-flags route, we should translate glibc-specific
> flags to kernel flags anyway because the kernel might introduce new
> flags which break the interface in subtle ways (see O_TMPFILE and mode
> argument handling).
An initial stab at the interface; it should avoid the problem you've
described above? I don't think additional rewrite of clone flags would
be required with such interface, even with future changes in the
kernel - in any case, using it requires good understanding of the
underlying kernel's clone() interface.
/* fork with flags */
pid_t ffork(int mode, unsigned long flags);
mode:
FFORK_FLAG_SET - set flags directly
FFORK_FLAG_OR - append flags to whatever fork uses internally
flags:
as with clone()
ret val / errno:
as with fork()
--
Robert Święcki