Re: Caching of PID/TID after fork

["Robert Święcki" <robert@swiecki.net>]

>> 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