unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
* thread safe functions
@ 2010-08-05 11:27 Cedric Cellier
  2010-08-18 15:56 ` Andy Wingo
  0 siblings, 1 reply; 5+ messages in thread
From: Cedric Cellier @ 2010-08-05 11:27 UTC (permalink / raw)
  To: guile-user

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.

And in general I think this info would be good to have for every
functions.




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: thread safe functions
  2010-08-05 11:27 thread safe functions Cedric Cellier
@ 2010-08-18 15:56 ` Andy Wingo
  2010-08-21  1:35   ` rixed
  0 siblings, 1 reply; 5+ messages in thread
From: Andy Wingo @ 2010-08-18 15:56 UTC (permalink / raw)
  To: Cedric Cellier; +Cc: guile-user

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/



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: thread safe functions
  2010-08-18 15:56 ` Andy Wingo
@ 2010-08-21  1:35   ` rixed
  2010-08-23  9:36     ` Ludovic Courtès
  2010-12-18 12:16     ` Andy Wingo
  0 siblings, 2 replies; 5+ messages in thread
From: rixed @ 2010-08-21  1:35 UTC (permalink / raw)
  To: Andy Wingo; +Cc: guile-user

[-- Attachment #1: Type: text/plain, Size: 353 bytes --]

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

Well, apparently for format this was already known, see the last sentence of this old msg from Marius Vollmer :

http://www.mail-archive.com/bug-guile@gnu.org/msg01949.html

But if you want an entry in the bug tracker I can add one :-)

[-- Attachment #2: Type: text/html, Size: 759 bytes --]

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: thread safe functions
  2010-08-21  1:35   ` rixed
@ 2010-08-23  9:36     ` Ludovic Courtès
  2010-12-18 12:16     ` Andy Wingo
  1 sibling, 0 replies; 5+ messages in thread
From: Ludovic Courtès @ 2010-08-23  9:36 UTC (permalink / raw)
  To: guile-user

Hi,

rixed@happyleptic.org writes:

>> The same goes for Scheme code. If you have found something in `format'
>> that is not thread-safe, do let us know.
>
> Well, apparently for format this was already known, see the last sentence of this old msg from Marius Vollmer :
>
> http://www.mail-archive.com/bug-guile@gnu.org/msg01949.html
>
> But if you want an entry in the bug tracker I can add one :-)

Yes, please do!

Thanks,
Ludo’.




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: thread safe functions
  2010-08-21  1:35   ` rixed
  2010-08-23  9:36     ` Ludovic Courtès
@ 2010-12-18 12:16     ` Andy Wingo
  1 sibling, 0 replies; 5+ messages in thread
From: Andy Wingo @ 2010-12-18 12:16 UTC (permalink / raw)
  To: rixed; +Cc: guile-user

Greets,

On Sat 21 Aug 2010 03:35, rixed@happyleptic.org writes:

>> If you have found something in `format' that is not thread-safe, do
>> let us know.
>
> Well, apparently for format this was already known, see the last
> sentence of this old msg from Marius Vollmer :
>
> http://www.mail-archive.com/bug-guile@gnu.org/msg01949.html

I think this was fixed actually, in 

    commit 093d2ca9afb2cb71317fea221466fe0946c94062
    Author: Marius Vollmer <mvo@zagadka.de>
    Date:   Mon Sep 15 13:37:50 2003 +0000

        (format): Rewritten as a big letrec to make it reentrant.  No mutex is
        necessary.  Thanks to Clinton Ebadi!

I have poked format a bit because it was offensive to the eye; but I
don't know of any threadsafety issues there.

Cheers,

Andy
-- 
http://wingolog.org/



^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2010-12-18 12:16 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-08-05 11:27 thread safe functions Cedric Cellier
2010-08-18 15:56 ` Andy Wingo
2010-08-21  1:35   ` rixed
2010-08-23  9:36     ` Ludovic Courtès
2010-12-18 12:16     ` Andy Wingo

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).