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/
next prev parent 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).