Date: Sat, 12 Jan 2013 11:38:31 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Alfred Perlstein <bright@mu.org> Cc: freebsd-arch@freebsd.org Subject: Re: Fast sigblock (AKA rtld speedup) Message-ID: <20130112093831.GK2561@kib.kiev.ua> In-Reply-To: <50F12A27.1000103@mu.org> References: <20130107182235.GA65279@kib.kiev.ua> <20130111095459.GZ2561@kib.kiev.ua> <50EFE830.3030500@freebsd.org> <20130111204938.GD2561@kib.kiev.ua> <20130111232906.GA29017@stack.nl> <50F0ADDA.4000801@gmail.com> <20130112053252.GI2561@kib.kiev.ua> <50F12A27.1000103@mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--PFhoI1KhOsYPpkJR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jan 12, 2013 at 04:17:27AM -0500, Alfred Perlstein wrote: > On 1/12/13 12:32 AM, Konstantin Belousov wrote: > > On Sat, Jan 12, 2013 at 08:27:06AM +0800, David Xu wrote: > >> On 2013/01/12 07:29, 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 > >>> The new fields td_sigblock_ptr and td_sigblock_val are in the part th= at > >>> is zeroed for new threads, while the code in rtld appears to expect t= hem > >>> to be copied (on fork, vfork and pthread_create). The fields are > >>> correctly zeroed on exec. > >>> > >>> Sharing the magic variable between threads means that one thread hold= ing > >>> 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 whet= her > >>> 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. > >>> > >>> Although libthr's postpone approach is somewhat ugly, it does not dep= end > >>> 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 vari= ous > >>> threading concepts, though. > >> Long time ago, if i remembered correctly, kib said that he wanted to > >> merge libthr code into libc, I don't know its state. > > Yes, this is correct, and I still want this. >=20 > Can we just do this already? I estimate the initial efforts for this as 2-3 weeks of full-time work. >=20 > No offense intended if the challenge is technical, I'm assuming it's=20 > political? >=20 > It's only 10 years overdue. The KSE was removed in 2008, so it could only be done for the 5 years. That said, the hardest issue with the merge is to preserve the ABI, esp. in regard to the libthr and its namespace. For the binaries, the threading symbols still must come from the libthr, while the merge left as an implementation detail. I implemented the required features for rtld, namely ELF filters support, not so long time ago, and there were still bug fixes as recent as of 2012, after libstdc++ was split. Also, we do not want the threading initialized before first additional thread is created, as well as we do not want libc to use real locking primitives before that. The same holds for rtld locks. The main motivation for the merge is the loadable modules which are linked against -lpthread, while the process which loads them is not. Since libthr interposes several libc interfaces, such processes end up with the completely broken linkage. As an example, the errno is still resolved to the single-threaded function, so the checks for the error cause return garbage after libthr load. I tried to cover the issue by marking libthr as not dlopen-able, but the outcry was too loud. --PFhoI1KhOsYPpkJR Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ8S8XAAoJEJDCuSvBvK1BFWAP/jqbY6Cxt3+PxxHReF3wggVf iBbKyRBGcsNuyBe5qPJuZWAQiQuO8aiCr3y5bbDTLampfbcY61NyWNhK4I7DlrXB E+++9AZAi0v9jPyXvblmNahBTxcBWpJuE2UX8OqPSU1kM8gCBCfgPqSUSoycSEWi uedzQ1ozN3jkmgiQCfPoq5FMVKzqMe9s2Co27d2wx8ZRR3oVijaIq2bfyRcu5J7T N1SuvNUZJYBxy6lFq8FA3CNmJLRmDlpfStS+zmROAJE+FDOio2x8C4FKa2U3zBa2 apDQiqOD5j47/OB7/dCmBT6MwORtzohAgOf7WEdGnhhV6MrTSUkExLIiWLNQ63Y8 0GBY4KK3+ewM8RXSSd2dsOeieub8F+nCgwelg2ePN/SicvYtKTO2iprFfYD2nUNt WVjQKliiOESZ8E7HxX3AIseexHYlUptiVTOLLKF80T/lal4cWnkDncbkBCQ3osqs 2XbWaj/qSAncCt82VfQucFksZwLI3i1A7zI5MOS9H1Llb3gZdsIOihuibGbj7O7X fgvRL/9H0+qm3tJZwjolXWdJiSEwkkzZFM96oRle29z8DH411de+tFBkX3fNVIMl paKi8ZeMyEGrVVzFH79UshEyJFpWLBApxqN+E+Wy/UaOoQfiUvzK38DsN5EaUU0/ 9VEZZwz83EKkxmEdAhju =5lYX -----END PGP SIGNATURE----- --PFhoI1KhOsYPpkJR--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130112093831.GK2561>