Date: Sat, 12 Jan 2013 07:31:48 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Jilles Tjoelker <jilles@stack.nl> Cc: arch@freebsd.org, toolchain@freebsd.org Subject: Re: Fast sigblock (AKA rtld speedup) Message-ID: <20130112053147.GH2561@kib.kiev.ua> In-Reply-To: <20130111232906.GA29017@stack.nl> References: <20130107182235.GA65279@kib.kiev.ua> <20130111095459.GZ2561@kib.kiev.ua> <50EFE830.3030500@freebsd.org> <20130111204938.GD2561@kib.kiev.ua> <20130111232906.GA29017@stack.nl>
next in thread | previous in thread | raw e-mail | index | archive | help
--1vEdgMWljt97yA53 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 12, 2013 at 12:29:06AM +0100, Jilles Tjoelker wrote: > On Fri, Jan 11, 2013 at 10:49:38PM +0200, Konstantin Belousov wrote: > > http://people.freebsd.org/~kib/misc/rtld-sigblock.3.patch >=20 > The new fields td_sigblock_ptr and td_sigblock_val are in the part that > is zeroed for new threads, while the code in rtld appears to expect them > to be copied (on fork, vfork and pthread_create). The fields are > correctly zeroed on exec. Thank you for noting this. Should be fixed in http://people.freebsd.org/~kib/misc/rtld-sigblock.4.patch >=20 > Sharing the magic variable between threads means that one thread holding > an rtld lock will block signals for all other threads as well. This is > different from how the normal signal mask works but I don't know whether > it may break things. However, the patch depends on it in some way > because sigtd() does not know about fast sigblock and will therefore > happily select a thread that is fast-sigblocking to handle a signal > directed at the process. Hm, I do not quite follow, at least not the first part of the paragraph. The fast sigblock pointer is per-thread, so it is not shared in the kernel. Regardless of the kernel side, rtld is only supposed to use the fast block in the default implementation of the rtld locks, which are overriden by the libthr implementation on libthr initialization. There is also an explicit hand-off from the default locks to the external (libthr), and rtld cares to turn off fast sigblock mechanism when the handoff is performed. The selection of the thread for the delivery of signal in the mt process should not matter then, due to the mechanism not supposed to be used in the mt process. >=20 > Although libthr's postpone approach is somewhat ugly, it does not depend > on any non-standard kernel features and does not delay the default > action. Would it be possible to move that code to libc to make things > easier for rtld? It looks like this requires teaching libc about various > threading concepts, though. The concern there is that rtld would need to have a tight coupling with libc, and possibly with libthr too. >=20 > Something feels ugly about not allowing applications to use this, > although I don't know how it would work. On the other hand, the strange > signal state created by this and implicit assumptions that the duration > will be short may be a reason to restrict its use to a relatively small > piece of code. Application use of the interface is equivalent to the application willingly corrupt its own state. --1vEdgMWljt97yA53 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ8PVDAAoJEJDCuSvBvK1BoRkQAI5otpa95LCidyeDwAW/TN2w R+VMZahZeIGNS8SWABgZnDqBfDHmwnIUDmg4Em/2z/yutPbBr74cl2h7JCCXLwaj FidmiaC18+O8AY68ir9uqt4QGt7VlNbcDutb9KSghdbFVVl0qF18OBNckv5jhltl sQu53uKng5x4DMP3yGxn/7icQVRr1koOwQJku1H7af1c39VIvpjbgLFBucfKlwVX LQkpk5EcjjvjL+SSTVzQJrSzvulj+bE2OXH+24QN+mClY07SjjAgHrASH/SHulAl UkN7H8XqoAEK7YYdz2lDedSOlYmkstykoFuoVbQhTvU+7PN23aEvNkOpi+UUFcZN ZHd45SiQ1/LHNC8W3CUnPzDNEcTMxkdYoNe0qKw43ZkaLgIrFVgM9Je9Ouy+QRCX ij/Y55X4UdqHhBG5dOGg/cvYgjkStAPEVGW+Of0L1YlGxvUGizVU82FTsSszBrH7 Qv1o13mhs1Mas/NXCaP37G4hSJzmYjMBEXcgTYSKb3po07uDErilBx/hkCl+EGBD wU5e25CTQT284fWMB8xxgx7FQ6c0gTLkWeTHf0TBYHEWyt3qT//GrhJoFOm4uCJ8 vgyt+sAbaPLg8rWt26kUZuHnVn3e+n51aPk4hIFBreCAt6mg4HH6OV1yDVPwmwHW Ri1zZ8wEM3SAvomdsBwN =clJL -----END PGP SIGNATURE----- --1vEdgMWljt97yA53--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130112053147.GH2561>