From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: Cygwin port of Guile 2.2 Date: Mon, 15 May 2017 22:06:27 +0200 Message-ID: <87ziedopfg.fsf@pobox.com> 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> <87efw681hv.fsf@priss.frightenedpiglet.com> <87shkdrgpz.fsf@pobox.com> <878tm26u4t.fsf@priss.frightenedpiglet.com> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1494878823 22707 195.159.176.226 (15 May 2017 20:07:03 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 15 May 2017 20:07:03 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) Cc: 26858@debbugs.gnu.org, guile-devel@gnu.org To: Derek Upham Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Mon May 15 22:06:59 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 1dAMGd-0005i6-UT for guile-devel@m.gmane.org; Mon, 15 May 2017 22:06:56 +0200 Original-Received: from localhost ([::1]:38531 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dAMGj-0004D4-Jm for guile-devel@m.gmane.org; Mon, 15 May 2017 16:07:01 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55160) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dAMGR-00045K-Cn for guile-devel@gnu.org; Mon, 15 May 2017 16:06:44 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dAMGN-0000Xk-DU for guile-devel@gnu.org; Mon, 15 May 2017 16:06:43 -0400 Original-Received: from pb-sasl1.pobox.com ([64.147.108.66]:61803 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1dAMGN-0000Xe-6l for guile-devel@gnu.org; Mon, 15 May 2017 16:06:39 -0400 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id 36C8978584; Mon, 15 May 2017 16:06:37 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; s=sasl; bh=x7sst05TIF9A L2+PopTZToKAO+U=; b=cqZPrKg/fHzsg0Ho2Xne5KeA5+KnuvUcpwJHD+95Lv20 5FGRJibUfaQl/bubPM94yEbD/4hUBhEMVHc2J6TFnXfnxG4UO63id0GrSsEHJqAc 0s4ctH9B9XQ+gKu/HGm/hFjpKnIXL3baGqWil5XQBNKVzyEEzCOBM5pOy7/W8Ko= DomainKey-Signature: a=rsa-sha1; c=nofws; d=pobox.com; h=from:to:cc :subject:references:date:in-reply-to:message-id:mime-version :content-type:content-transfer-encoding; q=dns; s=sasl; b=LvK+MX KYzBnSmHkReBDF/dfI31z2hFii2D3vj3mSJCAng7SJAqyP6FjGAIXduYZAV9Zp9P +BuyR21gpV9LKHldx1KgpX/gU1PzVMZtZeXWQJ6VnS4AR3IJDGLB7aSzjDXoqlV2 VvsY0o6jehkttV2BF+PV8puaFssUOaGEJzOXA= Original-Received: from pb-sasl1.nyi.icgroup.com (unknown [127.0.0.1]) by pb-sasl1.pobox.com (Postfix) with ESMTP id 2EFBA78582; Mon, 15 May 2017 16:06:37 -0400 (EDT) Original-Received: from clucks (unknown [88.160.190.192]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by pb-sasl1.pobox.com (Postfix) with ESMTPSA id BFAD278581; Mon, 15 May 2017 16:06:35 -0400 (EDT) In-Reply-To: <878tm26u4t.fsf@priss.frightenedpiglet.com> (Derek Upham's message of "Fri, 12 May 2017 07:13:06 -0700") X-Pobox-Relay-ID: FFD099BA-39A9-11E7-9EFC-9BB2D5707B88-02397024!pb-sasl1.pobox.com X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 64.147.108.66 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:19150 Archived-At: Greets, On Fri 12 May 2017 16:13, Derek Upham writes: > Andy Wingo writes: > >> scm_join_thread isn't actually implemented in terms of >> scm_i_pthread_join any more. Probably that's what's going wrong here -- >> and probably that should be fixed to ensure that we actually join the >> thread. (Otherwise it would be a memory leak too AFAIU.) Bcc'ing >> bug-guile to create a bug for that. > > I noticed that scm_join_thread was calling back into Scheme-land. Are th= ese statements all correct? > > - We are using call-with-new-thread underneath the hood. Underneath the hood of what? :) > - call-with-new-thread is documented to return a Scheme object from a > thunk/handler. Any underlying pthreads should be implementation > details. Correct. In practice call-with-new-thread will create a pthread but I can imagine circumstances in which it might (in the future) spawn an auxiliary pthread for some reason, and I wouldn't want to rule that out. > - The spawned thread sends the Scheme object to the condition variable > as soon as the user thunk exits. Any number of operations can happen > afterwards; the thread is still running in Scheme-land at this point, > in call-with-new-thread=E2=80=99s wrapping thunk. > - join-thread waits on the condition variable only. These are implementation details. They are correct but probably the implementation should change to do the scm_i_pthread_join and we should guarantee that after the join, the thread is really dead. This is bug 26858. > So at the end of join-thread we need to add a call to > scm_i_pthread_join (which we implement in threads.c) to ensure that > the pthread is completely gone before that join-thread returns. Is > that accurate? Well... yes, but we have to ensure that we call scm_i_pthread_join at most once. I think calling pthread_join twice on a thread is undefined. So there are some gnarlies here. Need to fix this. > Unfortunately, I think the GC threads are going to end up being > immovable objects in the path to full process-form support. You can disable marker threads with the GC_MARKERS environment variable, and the finalization thread should come and go as needed. Probably this is not a blocker from your POV. Signal handling is probably the most serious issue; perhaps we can avoid the thread somehow, since we handle signals asynchronously anyway.. Andy