From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Newsgroups: gmane.lisp.guile.devel Subject: Re: Thread local storage Date: Wed, 07 Oct 2009 00:04:40 +0200 Message-ID: <87eipgyy9z.fsf@gnu.org> References: <877hv9a5z5.fsf@gnu.org> <87r5tgqn0g.fsf@ossau.uklinux.net> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1254866738 17184 80.91.229.12 (6 Oct 2009 22:05:38 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 6 Oct 2009 22:05:38 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Oct 07 00:05:28 2009 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.50) id 1MvI9u-0001d9-Rm for guile-devel@m.gmane.org; Wed, 07 Oct 2009 00:05:27 +0200 Original-Received: from localhost ([127.0.0.1]:50392 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MvI9u-0002qd-By for guile-devel@m.gmane.org; Tue, 06 Oct 2009 18:05:26 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MvI9r-0002pK-BH for guile-devel@gnu.org; Tue, 06 Oct 2009 18:05:23 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MvI9m-0002kA-N7 for guile-devel@gnu.org; Tue, 06 Oct 2009 18:05:22 -0400 Original-Received: from [199.232.76.173] (port=55701 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MvI9m-0002k2-Ju for guile-devel@gnu.org; Tue, 06 Oct 2009 18:05:18 -0400 Original-Received: from lo.gmane.org ([80.91.229.12]:46175) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1MvI9l-0007Zd-J5 for guile-devel@gnu.org; Tue, 06 Oct 2009 18:05:18 -0400 Original-Received: from list by lo.gmane.org with local (Exim 4.50) id 1MvI9k-0001Z0-5z for guile-devel@gnu.org; Wed, 07 Oct 2009 00:05:16 +0200 Original-Received: from reverse-83.fdn.fr ([80.67.176.83]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 07 Oct 2009 00:05:16 +0200 Original-Received: from ludo by reverse-83.fdn.fr with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 07 Oct 2009 00:05:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 88 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: reverse-83.fdn.fr X-URL: http://www.fdn.fr/~lcourtes/ X-Revolutionary-Date: 15 =?iso-8859-1?Q?Vend=E9miaire?= an 218 de la =?iso-8859-1?Q?R=E9volution?= X-PGP-Key-ID: 0xEA52ECF4 X-PGP-Key: http://www.fdn.fr/~lcourtes/ludovic.asc X-PGP-Fingerprint: 821D 815D 902A 7EAB 5CEE D120 7FBA 3D4F EB1F 5364 X-OS: x86_64-unknown-linux-gnu User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) Cancel-Lock: sha1:y4NHgSjVGfX6833MUbCsSbd5g6A= X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:9458 Archived-At: Hello, Neil Jerram writes: > ludo@gnu.org (Ludovic Courtès) writes: > >> I looked again at how/whether we could improve thread-local storage >> access, using compiler support (the ‘__thread’ storage class). > > I worry a bit about having another build option, that might end up not > used and so bitrotting. Right, it increases the configuration space, and in practice most people will end up using ‘__thread’. OTOH I think the change is quite isolated, since we have only one thread-local variable. > Also I wonder, if #1 is always better than the > current implementation of pthread_getspecific, why the implementation of > pthread_getspecific isn't rewritten so that it uses #1 inside. Maybe > the signature of the pthread_getspecific API doesn't allow that. pthread_getspecific(3) is a function, whereas ‘__thread’ requires support from the compiler and dynamic linker. >> So #3 is appealing (~8% speedup on ‘gcbench’, ~10% on 30 iterations of >> ‘nboyer’). Unfortunately it’s not generally applicable to libguile >> since libguile may be dlopened (e.g., the XChat-Guile plug-in). > > (I presume it's actually the plug-in that gets dlopened, and the plug-in > links to libguile. I also presume that that doesn't make any difference > in practice.) Yes. >> The relevant work in ‘wip-tls’: >> >> commit 8346727c49c51a9668f10b507daff62dd889850a >> Author: Ludovic Courtès >> Date: Fri Oct 2 15:02:52 2009 +0200 >> >> Deprecate `scm_mask_ints'. > > Is there any replacement, or is this something that there was never any > reason to expose? It would be good for the deprecation comment to say a > bit more to justify the deprecation. I didn’t understand the point of this macro, and it’s not documented, which is why the deprecation message doesn’t suggest any replacement. Actually, it seems that it was used as an lvalue to mask block asyncs: http://google.com/codesearch?q=scm_mask_ints&hl=en&btnG=Search+Code In that case, I don’t know how we could provide a useful compatibility layer. Should we worry? >> commit b9619bff4ddff267149e7e869ef3c2bcb9c4f4b4 >> Author: Ludovic Courtès >> Date: Fri Oct 2 15:28:29 2009 +0200 >> >> Arrange so that `SCM_I_CURRENT_THREAD' is not accessed outside of libguile. > > This is great. I recommend writing the NEWS soon too, so as not to > build up a backlog of such items that have been removed from the API. Well, Andy has been very good at it so far. ;-) Besides, ‘SCM_I_CURRENT_THREAD’ is *not* part of the API. > + [AC_COMPILE_IFELSE([AC_LANG_PROGRAM([static __thread int tls_integer;], > + [tls_integer = 123;])], > > Since we don't use static for scm_i_current_thread, I guess it would be > a more accurate test not to use static here. Yes, why not. > + pf ("/* Define the 1 if the compiler supports the " > + "`__thread' storage class. */\n"); > > s/Define the/Define as/ Noted. Thanks, Ludo’.