From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: szgyg Newsgroups: gmane.lisp.guile.devel Subject: Re: Cygwin port of Guile 2.2 Date: Wed, 3 May 2017 11:39:28 +0200 Message-ID: <20170503093928.GA1344@debbie.mshome.net> References: <874ly49l54.fsf@joshua.spikycactus.dnsalias.com> <87lgr38jzd.fsf@pobox.com> <87pogft8c2.fsf@priss.frightenedpiglet.com> <878tmz7945.fsf@pobox.com> <87ziffcbwg.fsf@priss.frightenedpiglet.com> <87ziew4836.fsf@priss.frightenedpiglet.com> <8760hjt5k0.fsf@pobox.com> <87r306d3vx.fsf@priss.frightenedpiglet.com> <87lgqes375.fsf@pobox.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1493804103 29065 195.159.176.226 (3 May 2017 09:35:03 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 3 May 2017 09:35:03 +0000 (UTC) User-Agent: Mutt/1.6.0 (2016-04-01) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Wed May 03 11:34:51 2017 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d5qgM-0007I6-GL for guile-devel@m.gmane.org; Wed, 03 May 2017 11:34:50 +0200 Original-Received: from localhost ([::1]:35502 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d5qgS-0002nY-0k for guile-devel@m.gmane.org; Wed, 03 May 2017 05:34:56 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:41459) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d5qgJ-0002nR-RL for guile-devel@gnu.org; Wed, 03 May 2017 05:34:49 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d5qgG-00025j-NO for guile-devel@gnu.org; Wed, 03 May 2017 05:34:47 -0400 Original-Received: from mx3.mail.elte.hu ([157.181.1.138]:60166) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1d5qgG-00024j-GZ for guile-devel@gnu.org; Wed, 03 May 2017 05:34:44 -0400 Original-Received: from mailbox1.caesar.elte.hu ([157.181.151.157]) by mx3.mail.elte.hu with esmtp (Exim) id 1d5qgC-0005O7-Sy from for ; Wed, 03 May 2017 11:34:41 +0200 Original-Received: (Authenticated sender: szgyg) by mailbox1.caesar.elte.hu with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1d5qgC-0000VX-ME for guile-devel@gnu.org; Wed, 03 May 2017 11:34:40 +0200 Content-Disposition: inline In-Reply-To: <87lgqes375.fsf@pobox.com> X-ELTE-SpamScore: -6.5 X-ELTE-SpamLevel: X-ELTE-SpamCheck: no X-ELTE-SpamVersion: ELTE 3.0 X-ELTE-SpamCheck-Details: score=-6.5 required=5.0 tests=ALL_TRUSTED, L_AUTH, RP_MATCHES_RCVD autolearn=ham autolearn_force=no SpamAssassin version=3.4.0 -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -5.0 L_AUTH Caesar auth -0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 157.181.1.138 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: "guile-devel" Xref: news.gmane.org gmane.lisp.guile.devel:19127 Archived-At: On Wed, May 03, 2017 at 11:24:30AM +0200, Andy Wingo wrote: > On Wed 03 May 2017 05:18, Derek Upham writes: > > > Andy Wingo writes: > > > >> On Mon 01 May 2017 22:48, Derek Upham writes: > >> > >>> Running pthread_join() on a thread only guarantees that the thread has > >>> returned an exit value. > >> > >> Would you mind providing a reference please? It is not that I don't > >> believe you but I think it's important to know whether this is a bug in > >> Guile or in the pthreads implementation. > > > > It’s not explicit, but it’s heavily implied by the pthread_exit(3) man > > page: > > A specific implementation's man page is interesting but not the > specification. The specification is "The Open Group Base Specifications > Issue 7 IEEE Std 1003.1-2008, 2016 Edition" and can be found here: > > http://pubs.opengroup.org/onlinepubs/9699919799/ > > Note that pthread_exit() is not the normal way for a Guile thread to > exit. I thought we removed uses of this but I see that there are a > couple more that need to be removed. Are you using it? It's certainly > not one that we suggest. We don't use pthread_cleanup_push either -- > the lifetime of the thread from Guile's POV isn't limited to a dynamic > extent of scm_with_guile, as the thread could be created by the user, as > > https://lists.gnu.org/archive/html/guile-devel/2011-04/msg00133.html > > Anyway, I digress. After looking at the specification of pthread_join > (http://pubs.opengroup.org/onlinepubs/9699919799/functions/pthread_join.html), > things do not seem clear to me. Does the thread "terminate" before or > after the pthread_key destructors run? Given that: > > * pthread_key destructors must run in the thread AFAIU; to be able to > call pthread_setspecific in a destructor you need a fresh > or from a fresh new thread, and spawning a new thread to run cleanup > seems unlikely > > * pthread_key destructors can call any function > > I think there's an argument that a thread doesn't "terminate" until its > thread-local key destructors have finished running, and therefore > pthread_join doesn't return until after the key destructors have run. > This is my understanding of what happens from reading NPTL. Do I > understand correctly that you are on Cygwin? Could it be a cygwin > pthreads incompatibility? > > Andy > http://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_09 2.9.5 Thread Cancellation Thread Cancellation Cleanup Handlers #v+ After all cancellation cleanup handlers and thread-specific data destructors have returned, thread execution is terminated. #v- szgyg