Date: Sat, 12 Jan 2013 08:27:06 +0800 From: David Xu <listlog2011@gmail.com> To: Jilles Tjoelker <jilles@stack.nl> Cc: Konstantin Belousov <kostikbel@gmail.com>, arch@freebsd.org, toolchain@freebsd.org Subject: Re: Fast sigblock (AKA rtld speedup) Message-ID: <50F0ADDA.4000801@gmail.com> 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
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. > 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. > True, it seems it is for short duration.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?50F0ADDA.4000801>