Seems this interface be acceptable ?
Looks good to me.
The proposed code changes are in the attached patch.
Proposed wording of addition into RFORK(2):
DESCRIPTION:
RFTSIGZMB If set, the kernel will return selected signal number instead
of SIGCHILD upon thread exit
Below is the patch I intend to commit after you retest it.
I applied it against our 8.2 based package,
altered our clone to use this new
interface and run eglibc testsuite. No regression.
Our runtime detection of this new interface will be based
on sysctl kern.osreldate.
some rewording to
I will bump revision for stable/8 when merging, but I do not see much
reason to bump on HEAD right now.
Many thanks.
Uhm I think we can survive without a bump in HEAD. For now we will
need to keep our backward-compatibility patch anyway, and when the
bump happens on stable/8 our sysctl
RFLINUXPTH was used by the linuxthreads port, that was popular in the
time of FreeBSD 4.x and may be 5.x to run mysql. I will object against
this breakage.
Do I understand correctly that API/ABI backward compatibility with
previous FreeBSD releases w.r.t RFLINUXPTH is needed ?
The 1st patch
Can you, please, describe the reasoning behind the
+ if (sig == SIGCHLD) sig = 0;
line ?
The main reason is backward compatibility.
The original FreeBSD code allows only to select between
SIGUSR1 or SIGCHLD signals.
The our extension changes meaning of RFLINUXTHPN to select
The 1st patch satisfies this. I agree that SIGCHLD part
is not easily readable.
The SIGCHLD part is ugly. This is why I am asking about possible ways
to overcome this.
We need a way to specify no signal.
It can be new flag or ugly SIGCHLD.
new flag:
pros: cleaner design
cons: one bit of
I would instead use a new flag to specify a signal sent on the child
death. Like RFTSIGZMB. If flag is not set, SIGCHLD is used. If it is
set, the bit slice is used as signal number, 0 means do not send any
signal.
Please note that the signal should be checked for validity, it must be
=
Should the bit slice be 7 or 8 bits ?
I propose to go 8 bits, and add the check to be future-proof.
It seems that we already parse GNU/kFreeBSD brandnote. I think this
could be used to distinguish between old behaviour, that is currently
used by your libc, and proposed new interface, if
