Date: Sat, 12 Jan 2013 09:21:56 -0800 From: Julian Elischer <julian@freebsd.org> To: Konstantin Belousov <kostikbel@gmail.com> Cc: arch@freebsd.org, Jilles Tjoelker <jilles@stack.nl>, toolchain@freebsd.org Subject: Re: Fast sigblock (AKA rtld speedup) Message-ID: <50F19BB4.6080309@freebsd.org> In-Reply-To: <20130112053147.GH2561@kib.kiev.ua> References: <20130107182235.GA65279@kib.kiev.ua> <20130111095459.GZ2561@kib.kiev.ua> <50EFE830.3030500@freebsd.org> <20130111204938.GD2561@kib.kiev.ua> <20130111232906.GA29017@stack.nl> <20130112053147.GH2561@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
On 1/11/13 9:31 PM, Konstantin Belousov wrote: > 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 >> 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 > >> 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. I assume that the thread notifies the kernel of the location.. Might I suggest as a saftybelt that on notification of this address that the kernel requires that a known "magic" value be in this location as proof that all is as expected.? just a thought. > > 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. >> 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. > >> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50F19BB4.6080309>