[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: guile threading deadlock
From: |
Ludovic Courtès |
Subject: |
Re: guile threading deadlock |
Date: |
Sun, 09 Nov 2008 22:14:18 +0100 |
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.3 (gnu/linux) |
Hi,
"Linas Vepstas" <address@hidden> 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'.
- guile threading deadlock, Linas Vepstas, 2008/11/07
- Re: guile threading deadlock, Ludovic Courtès, 2008/11/08
- Re: guile threading deadlock, Linas Vepstas, 2008/11/08
- Re: guile threading deadlock, Ludovic Courtès, 2008/11/09
- Re: guile threading deadlock, Linas Vepstas, 2008/11/09
- Re: guile threading deadlock,
Ludovic Courtès <=
- Re: guile threading deadlock, Linas Vepstas, 2008/11/09
- Re: guile threading deadlock, Ludovic Courtès, 2008/11/09
- Re: guile threading deadlock, Linas Vepstas, 2008/11/10