Fast sigblock (AKA rtld speedup)

[Konstantin Belousov]

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.

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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 834 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-toolchain/attachments/20130112/b4c9ec00/attachment.sig>