guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Unbound variable across threads in C++ application


From: Lluís Vilanova
Subject: Re: Unbound variable across threads in C++ application
Date: Tue, 04 Oct 2016 13:13:50 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Lluís Vilanova writes:

> Hi! I'm not sure if this is the proper place to ask about this, but I saw no
> other mailing list.

> I have a C++ program that I want to extend with guile. It have two threads, 
> the
> first one defines a variable, while the second one prints its
> value. Nonetheless, the second thread barfs saying that the variable is not
> bound.

> I've ensured the ordering is correct, and reading through the reference manual
> seems to point to this being correct (pseudo-pseudo-code):

>   int main() {
>       scm_init_guile();
>       scm_c_eval("(define variable 1)");
>       scm_c_eval("(format #t \">> 1 >> ~s\" variable)");

>       std::thread t1([]() {
>           scm_init_guile();
>           scm_c_eval("(format #t \">> 2 >> ~s\" variable)");
>       });
>       t1.join();
>   }

> I've actually wrapped all my calls to guile to print helpful exception
> backtraces. Here's what I get when accessing variable on the second thread 
> (the
> variable is named "qi-args"):

>   Guile backtrace:
>   In unknown file:
>      ?: 6 [call-with-input-string "(format #t \">> 2 >> ~s\\n\" qi-args)\n" 
> ...]
>   In ice-9/boot-9.scm:
>   2401: 5 [save-module-excursion #<procedure 55a3af3d5db0 at 
> ice-9/eval-string.scm:65:9 ()>]
>   In ice-9/eval-string.scm:
>     44: 4 [read-and-eval #<input: string 55a3af464ea0> #:lang ...]
>     37: 3 [lp (format #t ">> 2 >> ~s\n" qi-args)]
>   In ice-9/eval.scm:
>    387: 2 [eval # ()]
>    393: 1 [eval #<memoized qi-args> ()]
>   In unknown file:
>      ?: 0 [memoize-variable-access! #<memoized qi-args> #<directory # 
> 55a3af104c60>]
>   qdbi-guile: unbound-variable: (#f "Unbound variable: ~S" (qi-args) #f)


> Any ideas what might be going wrong?

Ok, so it turns out my real application is a bit more complicated than this, and
the errors were due to namespacing the variables (code loaded after defining a
module).

Sorry about the noise.


Cheers,
  Lluis



reply via email to

[Prev in Thread] Current Thread [Next in Thread]