Date: Mon, 11 Jul 2011 20:24:08 +0300 From: Kostik Belousov <kostikbel@gmail.com> To: Petr Salinger <Petr.Salinger@seznam.cz> Cc: freebsd-hackers@freebsd.org, Robert Millan <rmh@debian.org>, current@freebsd.org Subject: Re: [PATCH] Improve LinuxThreads compatibility in rfork() Message-ID: <20110711172408.GX43872@deviant.kiev.zoral.com.ua> In-Reply-To: <alpine.LRH.2.02.1107111805350.7134@sci.felk.cvut.cz> References: <20110711123332.GS43872@deviant.kiev.zoral.com.ua> <alpine.LRH.2.02.1107111455230.7134@sci.felk.cvut.cz> <20110711133342.GT43872@deviant.kiev.zoral.com.ua> <alpine.LRH.2.02.1107111556000.7134@sci.felk.cvut.cz> <20110711142232.GU43872@deviant.kiev.zoral.com.ua> <alpine.LRH.2.02.1107111641340.7134@sci.felk.cvut.cz> <20110711150614.GV43872@deviant.kiev.zoral.com.ua> <alpine.LRH.2.02.1107111718440.7134@sci.felk.cvut.cz> <20110711154102.GW43872@deviant.kiev.zoral.com.ua> <alpine.LRH.2.02.1107111805350.7134@sci.felk.cvut.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
--TOkWJigZa0YodlBE Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jul 11, 2011 at 06:12:15PM +0200, Petr Salinger wrote: > >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 > ><=3D _SIG_MAXSIG). >=20 > We used this: >=20 > #define RFTHPNSHIFT 24 /* reserve bits 24-30 */ > #define RFTHPNMASK 0x7F /* for compatibility with=20 > linuxthreads/clone() */ > /* allow to specify "clone exit parent=20 > notification" signal */ > #define RFTHPNSIGNUM(flags) (((flags) >> RFTHPNSHIFT) & RFTHPNMASK) >=20 > Therefore signal #128 (_SIG_MAXSIG) cannot be selected. >=20 > 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 __FreeBSD_version is bumped and honored by glibc. You might need to store the brandinfo somewhere in struct proc or use the separate struct sysentvec. --TOkWJigZa0YodlBE Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (FreeBSD) iEYEARECAAYFAk4bMbgACgkQC3+MBN1Mb4gEcACfdj7xc3GIUFHXKmc7JIeohaMR zcMAn2rCwH7+ioEK42bpY+4iDFftWu2j =bNtr -----END PGP SIGNATURE----- --TOkWJigZa0YodlBE--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20110711172408.GX43872>