From: ludo@gnu.org (Ludovic Courtès)
To: guile-user@gnu.org
Subject: Re: guile threading deadlock
Date: Sun, 09 Nov 2008 22:14:18 +0100 [thread overview]
Message-ID: <87k5bclhzp.fsf@gnu.org> (raw)
In-Reply-To: 3ae3aa420811091147lfb3f37cjddd429d916887064@mail.gmail.com
Hi,
"Linas Vepstas" <linasvepstas@gmail.com> writes:
> scm_without_guile is also clearly not an option [...]. Its rather
> ludicrous to even suggest that such wrappers be used -- typically,
> such things are not ever within reach of the developer.
[...]
> I found a simple solution that works for me: just wrap
> calls to scm_c_eval_string() with calls to scm_with_guile().
Looks like you changed your mind by the end of the message! ;-)
> Yes, well, I eventually figured it out. The very first sentence
> of http://www.gnu.org/software/guile/manual/html_node/Blocking.html
>
> says it all: "A thread must not block outside of a libguile
> function while it is in guile mode. " Unfortunately, this
> sentence is completely missing from the section called
> "5.3 Initializing guile", which offers no hint of this behaviour.
Hmm, I don't think it's directly related to Guile initialization. How
would you like to change Section 5.3?
> Similarly, there is no hint of this in section 4.3.5
> "Multi-threading". Instead, I see sentences that say
> things like "a thread promises to reach a safe point
> reasonably frequently (see Asynchronous Signals)"
>
> What the heck is "a safe point"? Who is making the
> "promise"? Guile or the user app? What the heck do
> "safe points" have to do with signals? So I think that
> section is trying to warn about the deadlock, but fails
> utterly to actually come out and say it .... the
> documentation on this topic needs an overhaul.
I reread that part and the rest of the paragraph makes it clearer, IMO:
While in guile mode, a thread promises to reach a safe point
reasonably frequently (*note Asynchronous Signals::). In addition to
running signal handlers, these points are also potential rendezvous
points of all guile mode threads where Guile can orchestrate global
things like garbage collection. Consequently, when a thread in guile
mode blocks and does no longer frequent safe points, it might cause
all other guile mode threads to block as well. To prevent this from
happening, a guile mode thread should either only block in libguile
functions (who know how to do it right), or should temporarily leave
guile mode with `scm_without_guile'.
Note also that one of the first sentences of that section is:
Each thread that wants to use functions from libguile must put
itself into _guile mode_ and must then follow a few rules.
IMO this indicates that "reaching a safe point frequently" is one of
these rules.
Nonetheless, I agree that "safe point" should be defined, or a different
wording should be used.
Do you have any suggestions to clarify that?
> I suppose I could volunteer to provide updated documentation,
Yes! :-)
Thanks,
Ludo'.
next prev parent reply other threads:[~2008-11-09 21:14 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-08 2:26 guile threading deadlock Linas Vepstas
2008-11-08 12:25 ` Ludovic Courtès
2008-11-08 18:29 ` Linas Vepstas
2008-11-09 17:13 ` Ludovic Courtès
2008-11-09 19:47 ` Linas Vepstas
2008-11-09 21:14 ` Ludovic Courtès [this message]
2008-11-09 22:16 ` Linas Vepstas
2008-11-09 23:36 ` Ludovic Courtès
2008-11-10 23:59 ` Linas Vepstas
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=87k5bclhzp.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guile-user@gnu.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).