Fast sigblock (AKA rtld speedup)

Alfred Perlstein bright at mu.org
Sat Jan 12 09:17:33 UTC 2013


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 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.
>>>
>>> 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.
>>>
>>> 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.
>> 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.

Can we just do this already?

No offense intended if the challenge is technical, I'm assuming it's 
political?

It's only 10 years overdue.

-Alfred



More information about the freebsd-arch mailing list