From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Andy Wingo Newsgroups: gmane.lisp.guile.devel Subject: Re: wip-ports-refactor Date: Thu, 12 May 2016 08:16:21 +0200 Message-ID: <87shxnpzre.fsf@pobox.com> References: <87twjempnf.fsf@pobox.com> <20160424120519.2a44127e@bother.homenet> <87h9e6q92x.fsf@pobox.com> <20160511114254.6b87c024@bother.homenet> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1463033820 12218 80.91.229.3 (12 May 2016 06:17:00 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 12 May 2016 06:17:00 +0000 (UTC) Cc: guile-devel@gnu.org To: Chris Vine Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Thu May 12 08:16:51 2016 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1b0jvW-0002SY-Ee for guile-devel@m.gmane.org; Thu, 12 May 2016 08:16:50 +0200 Original-Received: from localhost ([::1]:55549 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b0jvV-0005kq-G4 for guile-devel@m.gmane.org; Thu, 12 May 2016 02:16:49 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:35171) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b0jvO-0005gY-JW for guile-devel@gnu.org; Thu, 12 May 2016 02:16:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1b0jvI-0007mH-KO for guile-devel@gnu.org; Thu, 12 May 2016 02:16:41 -0400 Original-Received: from pb-sasl2.pobox.com ([64.147.108.67]:53748 helo=sasl.smtp.pobox.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1b0jvI-0007m9-Dt for guile-devel@gnu.org; Thu, 12 May 2016 02:16:36 -0400 Original-Received: from sasl.smtp.pobox.com (unknown [127.0.0.1]) by pb-sasl2.pobox.com (Postfix) with ESMTP id C2F1211FEB; Thu, 12 May 2016 02:16:32 -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; s=sasl; bh=NX+93t99zG03R06TKPvM5lf0Gsc=; b=C7DzvI DobrFLU9yz/NAIwa3IBvqaq6BSZ2P4maaODG5px1Huzjli6nsJeEzwCzG/qnYiTL E2a8qqnu/YdEiuYFZMmIyoPXjaJGjTMROGSmUWUq3C6ie2x54mFkPazFWHIuvL7K 3v4/wXnUsGdm75EDCMCym7sjjm0ZMi86LtAZs= 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; q=dns; s=sasl; b=fEF0QhV4vrh7B8sLPD95hJQMSxBx5W6j 1eXzt7wp9YyNbgAwpYUmjQOKnGxSLU0NEBqUqrXM+xlZ9pgUYTN90RIusv8PzIKE ygiNWgqI3ktn3IgQSewjBBwF3HyijkAe8vqxGRJlUg63HWKiP9Rpw2E4N24wUBvG nsU8w+Q+Nm4= Original-Received: from pb-sasl2. (unknown [127.0.0.1]) by pb-sasl2.pobox.com (Postfix) with ESMTP id A0B4911FE7; Thu, 12 May 2016 02:16:32 -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-sasl2.pobox.com (Postfix) with ESMTPSA id B38D511FE5; Thu, 12 May 2016 02:16:31 -0400 (EDT) In-Reply-To: <20160511114254.6b87c024@bother.homenet> (Chris Vine's message of "Wed, 11 May 2016 11:42:54 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) X-Pobox-Relay-ID: 12274E1A-1809-11E6-AF52-D472793246D6-02397024!pb-sasl2.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.67 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:18306 Archived-At: On Wed 11 May 2016 12:42, Chris Vine writes: > So you are saying that some parts of guile rely on the ordering > guarantees of the x86 memory model (or something like it) with respect > to atomic operations on some internal localised shared state? Let's say you cons a fresh pair and pass it to another thread. So first Guile will allocate the pair then it will initialize the car and cdr fields. Does the other thread see the "car" and "cdr" values which the first one set? In Intel, yes. But not all architectures are like that. Storing a value to the "car" of a pair might not imply any ordering with respect to a read to that same memory location from another thread. AFAIU anyway. > Looking at the pthread related stuff in libguile, it seems to be > written by someone/people who know what they are doing. Are you > referring specifically to the guile VM, and if so is guile-2.2 likely > to be more problematic than guile-2.0? I think Guile 2.2 is likely to be better if only because the port situation is better there, and also weak maps are thread-safe (because they lock now). Otherwise no significant change. Andy