unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Andy Wingo <wingo@pobox.com>
To: Cedric Cellier <rixed@happyleptic.org>
Cc: guile-user@gnu.org
Subject: Re: thread safe functions
Date: Wed, 18 Aug 2010 08:56:15 -0700	[thread overview]
Message-ID: <m3vd77vrs0.fsf@unquote.localdomain> (raw)
In-Reply-To: <20100805112743.GA1671@securactive.net> (Cedric Cellier's message of "Thu, 5 Aug 2010 13:27:43 +0200")

Hi Cedric,

On Thu 05 Aug 2010 04:27, Cedric Cellier <rixed@happyleptic.org> writes:

> Is there somewhere a list of guile functions that are (/are not) thread
> safe ?
>
> I ask since this morning I was after a strange bug because I was using
> the format module in two different thread, then learnt that these
> functions are not reentrant. I'm also interrested in the thread-safeness
> of gc-stats function.

From "Multi-Threading" in the manual:

       All libguile functions are (intended to be) robust in the face of
    multiple threads using them concurrently.  This means that there is no
    risk of the internal data structures of libguile becoming corrupted in
    such a way that the process crashes.

       A program might still produce nonsensical results, though.  Taking
    hashtables as an example, Guile guarantees that you can use them from
    multiple threads concurrently and a hashtable will always remain a valid
    hashtable and Guile will not crash when you access it.  It does not
    guarantee, however, that inserting into it concurrently from two threads
    will give useful results: only one insertion might actually happen, none
    might happen, or the table might in general be modified in a totally
    arbitrary manner.  (It will still be a valid hashtable, but not the one
    that you might have expected.)  Guile might also signal an error when it
    detects a harmful race condition.

       Thus, you need to put in additional synchronizations when multiple
    threads want to use a single hashtable, or any other mutable Scheme
    object.

If you see any problem in libguile regarding threads, you should
certainly report it to bug-guile@gnu.org (no subscription required).

The same goes for Scheme code. If you have found something in `format'
that is not thread-safe, do let us know.

Thanks,

Andy
-- 
http://wingolog.org/



  reply	other threads:[~2010-08-18 15:56 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-08-05 11:27 thread safe functions Cedric Cellier
2010-08-18 15:56 ` Andy Wingo [this message]
2010-08-21  1:35   ` rixed
2010-08-23  9:36     ` Ludovic Courtès
2010-12-18 12:16     ` Andy Wingo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m3vd77vrs0.fsf@unquote.localdomain \
    --to=wingo@pobox.com \
    --cc=guile-user@gnu.org \
    --cc=rixed@happyleptic.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).