unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: "Linas Vepstas" <linasvepstas@gmail.com>
To: "Ludovic Courtès" <ludo@gnu.org>
Cc: guile-user@gnu.org
Subject: Re: guile threading deadlock
Date: Sun, 9 Nov 2008 13:47:18 -0600	[thread overview]
Message-ID: <3ae3aa420811091147lfb3f37cjddd429d916887064@mail.gmail.com> (raw)
In-Reply-To: <871vxkyg8h.fsf@gnu.org>

2008/11/9 Ludovic Courtès <ludo@gnu.org>:
> Hi,
>
> "Linas Vepstas" <linasvepstas@gmail.com> writes:
>
>> Anyway, I have an even simpler variant, with only *one*
>> thread deadlocked in gc.    Here's the scenario:
>>
>> thread A:
>>    scm_init_guile();
>>    does some other stuff, then
>>    goes to sleep in select, waiting on socket input
>>    (as expected).
>>
>> thread B:
>>    scm_init_guile() -- hangs here.
>
> Just to be sure: do you use raw select(2), `scm_std_select ()', or
> select(2) within `scm_without_guile ()'?

Raw select. I don't actually use it, its in some other library
that the project uses; wrapping it with a guile function is
not an option; its not code that we (the project) can even
control.

scm_without_guile is also clearly not an option, as it requires
an inversion of control.  In my app. guile is a bit player, just
another small guy inside a much larger framework; and so
anything invasive is just not possible. Similar remarks for
scm_pthread_mutex_lock(), etc.  Its rather ludicrous to even
suggest that such wrappers be used -- typically, such things
are not ever within reach of the developer.

> The first option would lead to the situation you're observing because
> Guile's GC requires thread to cooperate, which is why
> `scm_without_guile' exists (info "(guile) Blocking").

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.

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 found a simple solution that works for me: just wrap
calls to scm_c_eval_string()  with calls to scm_with_guile().

That is, I basically call
scm_with_guile(scm_c_eval_string, expr)
and so am *never* in "guile mode", except while evaluating
an expression.  This solution is "obvious", once one
understands it ... but again, the documentation doesn't
even hint this: scm_c_eval_string does not even hint that
wrapping it with scm_with_guile is going to be the "typical"
use case.  (well, I actually wrap it scm_c_catch first.. which
is also a whole under-documented area).

I suppose I could volunteer to provide updated documentation,
if someone can hold my hand during its creation.

--linas

  reply	other threads:[~2008-11-09 19:47 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 [this message]
2008-11-09 21:14         ` Ludovic Courtès
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=3ae3aa420811091147lfb3f37cjddd429d916887064@mail.gmail.com \
    --to=linasvepstas@gmail.com \
    --cc=guile-user@gnu.org \
    --cc=ludo@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).