From owner-freebsd-toolchain@FreeBSD.ORG Sat Jan 12 17:22:10 2013 Return-Path: Delivered-To: toolchain@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id BECBEB18; Sat, 12 Jan 2013 17:22:10 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id 8AA40123; Sat, 12 Jan 2013 17:22:10 +0000 (UTC) Received: from JRE-MBP-2.local (c-50-143-148-105.hsd1.ca.comcast.net [50.143.148.105]) (authenticated bits=0) by vps1.elischer.org (8.14.5/8.14.5) with ESMTP id r0CHM1JN020230 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 12 Jan 2013 09:22:01 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <50F19BB4.6080309@freebsd.org> Date: Sat, 12 Jan 2013 09:21:56 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130107 Thunderbird/17.0.2 MIME-Version: 1.0 To: Konstantin Belousov Subject: Re: Fast sigblock (AKA rtld speedup) 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> In-Reply-To: <20130112053147.GH2561@kib.kiev.ua> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: arch@freebsd.org, Jilles Tjoelker , toolchain@freebsd.org X-BeenThere: freebsd-toolchain@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Maintenance of FreeBSD's integrated toolchain List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Jan 2013 17:22:10 -0000 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.