Date: Sat, 12 Jan 2013 00:29:06 +0100 From: Jilles Tjoelker <jilles@stack.nl> To: Konstantin Belousov <kostikbel@gmail.com> Cc: arch@freebsd.org, toolchain@freebsd.org Subject: Re: Fast sigblock (AKA rtld speedup) Message-ID: <20130111232906.GA29017@stack.nl> In-Reply-To: <20130111204938.GD2561@kib.kiev.ua> References: <20130107182235.GA65279@kib.kiev.ua> <20130111095459.GZ2561@kib.kiev.ua> <50EFE830.3030500@freebsd.org> <20130111204938.GD2561@kib.kiev.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
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. 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. -- Jilles Tjoelker
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130111232906.GA29017>