From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.user Subject: Re: libguile thread safety Date: Sat, 04 Jan 2014 14:37:59 -0500 Message-ID: <87y52vzgfc.fsf@netris.org> References: <20140103233407.36382e5f@bother.homenet> <8738l41p8r.fsf@netris.org> <20140104124459.6c604ae1@bother.homenet> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1388864446 24156 80.91.229.3 (4 Jan 2014 19:40:46 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 4 Jan 2014 19:40:46 +0000 (UTC) Cc: guile-user@gnu.org To: Panicz Maciej Godek Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Sat Jan 04 20:40:51 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 1VzX5X-0004gB-Bq for guile-user@m.gmane.org; Sat, 04 Jan 2014 20:40:51 +0100 Original-Received: from localhost ([::1]:55542 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VzX5X-000763-0g for guile-user@m.gmane.org; Sat, 04 Jan 2014 14:40:51 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:46799) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VzX57-00073N-Ob for guile-user@gnu.org; Sat, 04 Jan 2014 14:40:31 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VzX50-0002VQ-Ch for guile-user@gnu.org; Sat, 04 Jan 2014 14:40:25 -0500 Original-Received: from world.peace.net ([96.39.62.75]:37840) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VzX50-0002UJ-9m for guile-user@gnu.org; Sat, 04 Jan 2014 14:40:18 -0500 Original-Received: from 209-6-197-194.c3-0.smr-ubr2.sbo-smr.ma.cable.rcn.com ([209.6.197.194] helo=yeeloong) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1VzX4h-0008Q3-Uc; Sat, 04 Jan 2014 14:40:00 -0500 In-Reply-To: (Panicz Maciej Godek's message of "Sat, 4 Jan 2014 16:01:35 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 96.39.62.75 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:10976 Archived-At: Panicz Maciej Godek writes: > 2014/1/4 Chris Vine : >> It seems as if top level variables in code evaluated by scm_c_eval_string() >> are shared between concurrently running threads. Is this really the >> intended behaviour (it is a significant and unexpected usability >> restriction)? Maciej (I hope that is your first name) can you reproduce >> this? > [...] > > It indeed does seem that the threads share their top-level bindings on > guile's side, and I suppose that this is the intended behaviour. I > think that it can be easily adjusted with scm_eval_string_in_module, > i.e. if you provide a separate module for each thread. Indeed, top-level bindings are always looked up in the "current module". Each thread has its own "current module", but 'scm_with_guile' initially sets the current module to (guile-user). That's usually desirable, because you may have bound your own application-specific procedures and global variables in (guile-user), and you want all threads to have access to those by default. The usual way to make thread-local variables in Guile is to use parameters[1] or fluids[2]. It's rather unusual to create fresh modules for each thread, but if you really want to do that you can start each thread by evaluating "(set-current-module (make-fresh-user-module))". [1] API Reference > Scheduling > Parameters (section 6.21.8) [2] API Reference > Scheduling > Fluids and Dynamic States (section 6.21.7) Mark