From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Panicz Maciej Godek Newsgroups: gmane.lisp.guile.user Subject: Re: libguile thread safety Date: Sat, 4 Jan 2014 23:43:22 +0100 Message-ID: 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=ISO-8859-1 X-Trace: ger.gmane.org 1388875408 942 80.91.229.3 (4 Jan 2014 22:43:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 4 Jan 2014 22:43:28 +0000 (UTC) Cc: "guile-user@gnu.org" To: Chris Vine Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sat Jan 04 23:43:35 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 1VzZwM-00040t-KD for guile-user@m.gmane.org; Sat, 04 Jan 2014 23:43:34 +0100 Original-Received: from localhost ([::1]:55955 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VzZwM-0004Xc-90 for guile-user@m.gmane.org; Sat, 04 Jan 2014 17:43:34 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48101) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VzZwD-0004XK-0U for guile-user@gnu.org; Sat, 04 Jan 2014 17:43:25 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VzZwB-0000S9-9V for guile-user@gnu.org; Sat, 04 Jan 2014 17:43:24 -0500 Original-Received: from mail-we0-x233.google.com ([2a00:1450:400c:c03::233]:47727) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VzZwB-0000Rn-2z for guile-user@gnu.org; Sat, 04 Jan 2014 17:43:23 -0500 Original-Received: by mail-we0-f179.google.com with SMTP id q59so14309089wes.24 for ; Sat, 04 Jan 2014 14:43:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=l5QftxcEpmwG4FDcKKL54MIPp1XAFMwiuvsjk9Lfaf0=; b=tuE/MsGNtQTDxniGWhsvjak8W7mAbpOLTFdX2ssaeM7ZLC2U5MnOqEfPss23WCmYDb 5GzXSdE/jGs37TfZlpjqdcdDhfrP4POLd8HC+TIDKmH6ge5vc9+f7VcxuYq/76HmYfLb 7J1UDVkIQnF7+V3MUvqujKs+graTKo20KVGfOITySw07L2dsfyRqrDoOen1rAxxcChIp frxIreBqq1sZsgbi8yuS2zuPFrbx3x2LQ1ev/DnOYnaZYt7Y2t27/hiv0XJdvhYEf0Af 12/KgLKqR6bTTk1PcLZXVLSkCFKx97UIrskvnfArNKdeRgt9PLPKYlFdYYlYa28ECml8 fciQ== X-Received: by 10.180.228.8 with SMTP id se8mr6725350wic.7.1388875402092; Sat, 04 Jan 2014 14:43:22 -0800 (PST) Original-Received: by 10.194.178.134 with HTTP; Sat, 4 Jan 2014 14:43:22 -0800 (PST) In-Reply-To: <20140104210118.3564073f@bother.homenet> X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c03::233 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:10979 Archived-At: 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) > make-fresh-user-module is not documented. It might be worth adding it > to the documentation. it definitely might ;)