From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Chris Vine Newsgroups: gmane.lisp.guile.user Subject: Re: libguile thread safety Date: Sat, 4 Jan 2014 23:31:20 +0000 Message-ID: <20140104233120.77b0edaa@bother.homenet> References: <20140103233407.36382e5f@bother.homenet> <8738l41p8r.fsf@netris.org> <20140104124459.6c604ae1@bother.homenet> <87y52vzgfc.fsf@netris.org> <20140104210118.3564073f@bother.homenet> 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 1388878295 29384 80.91.229.3 (4 Jan 2014 23:31:35 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 4 Jan 2014 23:31:35 +0000 (UTC) Cc: "guile-user@gnu.org" To: Panicz Maciej Godek Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sun Jan 05 00:31:41 2014 Return-path: Envelope-to: guile-user@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 1Vzags-0000jv-BG for guile-user@m.gmane.org; Sun, 05 Jan 2014 00:31:38 +0100 Original-Received: from localhost ([::1]:56079 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vzagr-0007NB-UD for guile-user@m.gmane.org; Sat, 04 Jan 2014 18:31:37 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53204) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vzagf-0007N1-Az for guile-user@gnu.org; Sat, 04 Jan 2014 18:31:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VzagZ-0003Si-BF for guile-user@gnu.org; Sat, 04 Jan 2014 18:31:25 -0500 Original-Received: from smtpout3.wanadoo.co.uk ([80.12.242.59]:53645 helo=smtpout.wanadoo.co.uk) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VzagZ-0003SS-1P for guile-user@gnu.org; Sat, 04 Jan 2014 18:31:19 -0500 Original-Received: from bother.homenet ([95.146.112.60]) by mwinf5d41 with ME id 9zXG1n00B1JEVaP03zXG7b; Sun, 05 Jan 2014 00:31:17 +0100 Original-Received: from bother.homenet (localhost [127.0.0.1]) by bother.homenet (Postfix) with ESMTP id ED83588504; Sat, 4 Jan 2014 23:31:20 +0000 (GMT) In-Reply-To: X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.22; 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-user@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:10980 Archived-At: On Sat, 4 Jan 2014 23:43:22 +0100 Panicz Maciej Godek wrote: > 2014/1/4 Chris Vine : > > Is it efficiency concerns that make you think it unusual, or just > > that the use case is unusual? > > I don't think that creating a new module is particularly inefficient, > and it would only become noticable if you were creating many many > threads with a short lifetime. What's unusual (and I think that Mark > would agree) is that you'd normally want your thread to be able to > access all the definitions that are visible to the program (or: to the > main thread). If a program is written in a functional style, the > threads usually don't mutate their global environment -- they just > read the definitions -- so any race conditions or other conflicts are > unlikely. > > I think that your use-case is different and that you make very few > assumptions on the code that the threads will execute -- in > particular, that it might be a highly imperative code which does > mutate its global state. If it is so, then I think that this is the > right way. (Be warned, that it doesn't protect the system from > malicious code -- it is still possible for a thread to modify the > content of another module, but it's difficult to do that by accident) The problem here isn't so much deliberate mutation of data, as top level name clashes causing silent unwanted mutation. But yes, in this usage task isolation is a positive virtue, not something to be regretted. We can assume no malicious intent (the house-keeping of any thread pool can be wrecked by the simple expedient of a task calling pthread_exit(): one must assume some competence and good faith on the part of the programmer). One purpose of top level variables at the module level here is to pass arguments to loaded scheme files. I actually have a prototype working well now, apart from the module issue Mark Weaver referred to, which I have to say has not yet bitten me but no doubt might. Chris