From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chris Vine Newsgroups: gmane.lisp.guile.devel Subject: Re: wip-ports-refactor Date: Sun, 24 Apr 2016 12:05:19 +0100 Message-ID: <20160424120519.2a44127e@bother.homenet> References: <87twjempnf.fsf@pobox.com> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1461495948 22618 80.91.229.3 (24 Apr 2016 11:05:48 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 24 Apr 2016 11:05:48 +0000 (UTC) To: guile-devel@gnu.org Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sun Apr 24 13:05:39 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 1auHr8-000150-QS for guile-devel@m.gmane.org; Sun, 24 Apr 2016 13:05:38 +0200 Original-Received: from localhost ([::1]:55028 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1auHr8-0006h4-5t for guile-devel@m.gmane.org; Sun, 24 Apr 2016 07:05:38 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45105) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1auHr0-0006bI-PV for guile-devel@gnu.org; Sun, 24 Apr 2016 07:05:34 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1auHqx-00080x-2q for guile-devel@gnu.org; Sun, 24 Apr 2016 07:05:30 -0400 Original-Received: from smtpout3.wanadoo.co.uk ([80.12.242.59]:23543 helo=smtpout.wanadoo.co.uk) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1auHqw-00080j-Mx for guile-devel@gnu.org; Sun, 24 Apr 2016 07:05:27 -0400 Original-Received: from bother.homenet ([95.146.110.221]) by mwinf5d41 with ME id mB5L1s0064mf7Yn03B5LaG; Sun, 24 Apr 2016 13:05:20 +0200 X-ME-Helo: bother.homenet X-ME-Date: Sun, 24 Apr 2016 13:05:20 +0200 X-ME-IP: 95.146.110.221 Original-Received: from bother.homenet (localhost [127.0.0.1]) by bother.homenet (Postfix) with ESMTP id EBF49120C59 for ; Sun, 24 Apr 2016 12:05:19 +0100 (BST) In-Reply-To: <87twjempnf.fsf@pobox.com> X-Mailer: Claws Mail 3.13.1 (GTK+ 2.24.30; i686-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 80.12.242.59 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:18293 Archived-At: On Wed, 06 Apr 2016 22:46:28 +0200 Andy Wingo wrote: > So, right now Guile has a pretty poor concurrency story. We just have > pthreads, which is great in many ways, but nobody feels like > recommending this to users. The reason is that when pthreads were > originally added to Guile, they were done in such a way that we could > assume that data races would just be OK. It's amazing to reflect upon > this, but that's how it is. Many internal parts of Guile are > vulnerable to corruption when run under multiple kernel threads in > parallel. Consider what happens when you try to load a module from > two threads at the same time. What happens? What should happen? > Should it be possible to load two modules in parallel? The system > hasn't really been designed as a whole. Guile has no memory model, > as such. We have patches over various issues, ad-hoc locks, but it's > not in a state where we can recommend that users seriously use > threads. I am not going to comment on the rest of your post, because you know far more about it than I could hope to, but on the question of guile's thread implementation, it seems to me to be basically sound if you avoid obvious global state. I have had test code running for hours, indeed days, without any appearance of data races or other incorrect behaviour on account of guile's thread implementation. Global state is an issue. Module loading (which you mention) is an obvious one, but other things like setting load paths don't look to be thread safe either. It would be disappointing to give up on the current thread implementation. Better I think in the interim is to document better what is not thread-safe. Some attempts at thread safety are in my view a waste of time anyway, including trying to produce individual ports which can safely be accessed in multiple threads. Multi-threading with ports requires the prevention of interleaving, not just the prevention of data races, and that is I think best done by locking at the user level rather than the library level. Co-operative multi-tasking using asynchronous frameworks such as 8sync or another one in which I have an interest, and pre-emptive multi-tasking using a scheduler and "green" threads, are all very well but they do not enable use of more than one processor, and more importantly (because I recognise that guile may not necessarily be intended for use cases needing multiple processors for performance reasons), they can be more difficult to use. In particular, anything which makes a blocking system call will wedge the whole program. Chris