From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Neil Jerram Newsgroups: gmane.lisp.guile.devel Subject: Re: Thread local storage Date: Wed, 07 Oct 2009 21:49:09 +0100 Message-ID: <874oqb7wvu.fsf@ossau.uklinux.net> References: <877hv9a5z5.fsf@gnu.org> <87r5tgqn0g.fsf@ossau.uklinux.net> <87eipgyy9z.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=gb2312 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1254948612 32571 80.91.229.12 (7 Oct 2009 20:50:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Wed, 7 Oct 2009 20:50:12 +0000 (UTC) Cc: guile-devel@gnu.org To: ludo@gnu.org (Ludovic =?iso-8859-1?Q?Court=E8s?=) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed Oct 07 22:50:02 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 1MvdSU-0002UT-0k for guile-devel@m.gmane.org; Wed, 07 Oct 2009 22:50:02 +0200 Original-Received: from localhost ([127.0.0.1]:41539 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MvdST-0004OP-IK for guile-devel@m.gmane.org; Wed, 07 Oct 2009 16:50:01 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MvdSQ-0004LV-6g for guile-devel@gnu.org; Wed, 07 Oct 2009 16:49:58 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MvdSL-0004Bj-61 for guile-devel@gnu.org; Wed, 07 Oct 2009 16:49:57 -0400 Original-Received: from [199.232.76.173] (port=53464 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MvdSL-0004BQ-0d for guile-devel@gnu.org; Wed, 07 Oct 2009 16:49:53 -0400 Original-Received: from mail3.uklinux.net ([80.84.72.33]:51415) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MvdSF-0002Vt-EB; Wed, 07 Oct 2009 16:49:47 -0400 Original-Received: from arudy (host86-145-159-48.range86-145.btcentralplus.com [86.145.159.48]) by mail3.uklinux.net (Postfix) with ESMTP id 151641F6B03; Wed, 7 Oct 2009 21:49:10 +0100 (BST) Original-Received: from arudy (arudy [127.0.0.1]) by arudy (Postfix) with ESMTP id 7ADA938023; Wed, 7 Oct 2009 21:49:09 +0100 (BST) In-Reply-To: <87eipgyy9z.fsf@gnu.org> ("Ludovic =?iso-8859-1?Q?Court=E8s?= =?iso-8859-1?Q?=22's?= message of "Wed, 07 Oct 2009 00:04:40 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.4-2.6 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:9466 Archived-At: ludo@gnu.org (Ludovic Court=A8=A8s) writes: > Right, it increases the configuration space, and in practice most people > will end up using =A1=AE__thread=A1=AF. OTOH I think the change is quite > isolated, since we have only one thread-local variable. Yes, I agree. >> 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 =A1=AE__thread=A1=AF requir= es > support from the compiler and dynamic linker. OK. >>> 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=A1=AFt understand the point of this macro, and it=A1=AFs not docum= ented, > which is why the deprecation message doesn=A1=AFt suggest any replacement. Well, I was going to suggest that we could add something like this sentence to the deprecation message. However... > Actually, it seems that it was used as an lvalue to mask block asyncs: > > http://google.com/codesearch?q=3Dscm_mask_ints&hl=3Den&btnG=3DSearch+Co= de ... this search makes it clear that there's not really any point in doing that, since no evidence of any current application Guile using scm_mask_ints. > In that case, I don=A1=AFt know how we could provide a useful compatibili= ty > layer. > > Should we worry? Given the above, no. >> 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, =A1=AESCM_I_CURRENT_THREAD=A1=AF is *not* part of the API. True, but I think I'd like the 2.0 NEWS to have an explicit entry saying that we have cleaned up API visibility, and listing the removed names. I have in mind to try to produce this myself before 2.0, using some systematic comparison of the headers and libraries, but it would help if we all start noting (i.e. in NEWS) removed names (and which we are sure _should_ be removed) as we go along, so as to reduce the task later of checking the removals that aren't already listed. What do you think? (Also note that this commit also removes SCM_STACK_OVERFLOW_P from the API. I guess that was never intended to be part of the API either.) Regards, Neil