On Mon, Jul 11, 2011 at 04:23:36PM +0200, Petr Salinger wrote: > >>>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 signal based on > >>bits 24-30 of passed flags instead of using SIGUSR1 every time. > >> > >>When the passed "signal" number is zero, it should behave identically > >>on plain FreeBSD and in our environment, therefore SIGUSR1 is selected. > >>The assumption is (have been) that (yet) undefined bits are zero. > >>That way we are backward compatible with original FreeBSD. > >> > >>We still need an alternative way to select "none signal is sent" > >>after child exit (under linux #0 is used). > >> > >>The SIGCHLD can be "selected" (also on original FreeBSD) by not specifying > >>RFLINUXTHPN, therefore combination of RFLINUXTHPN and passed "signal" > >>number SIGCHLD is (have been) used for "none signal". > >> > >>BTW, the opposite side is in > >> > >>http://anonscm.debian.org/viewvc/glibc-bsd/trunk/glibc-ports/kfreebsd/clone.c?view=markup > > > >I shall state that the sig == SIGCHLD case is ugly. Having the separate > >flag "do not send signal to the parent" would be much less clumsy. > >What are the requirements for the ABI stability for Debian/kFreeBSD ? > >Can this be fixed now, or is it too late ? > > It should be backward compatible with one previous version. > > What about in long term this: > > RFLINUXTHPN bit will be renamed and will have meaning > "select signal based on bits 24-30 of passed flags" > > - zero would mean "no signal" > - SIGCHLD would mean undefined > - SIGUSR1 would mean SIGUSR1 > > It is ABI/API breakage under original FreeBSD. > The question is how frequently RFLINUXTHPN is used under native FreeBSD > and its port collection. 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. > > And under "Debian GNU/kFreeBSD COMPAT" or 8-COMPAT > - SIGCHLD would mean "no signal" We never user COMPAT to _change_ the meaning of something, only to exclude some functionality, like syscall. > > We do not use SIGUSR1 currently, the eglibc side can detect whether > it runs under new-enough kernel and decide whether use 0 or SIGCHLD > for "no signal". > > The kernel side would be something like: > > if (flags & RFLINUXTHPN) > { > p2->p_sigparent = RFTHPNSIGNUM(flags); > #if COMPAT8 > if (p2->p_sigparent == SIGCHLD) > p2->p_sigparent = 0; > #endif > } No, this is even uglier, and see the note about compat. BTW, it seems that our rfork(2) ignores unknown flags. This should be fixed, might be in the same patch.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:15 UTC