On Sat, 4 Jan 2014 23:43:22 +0100
Panicz Maciej Godek wrote:
> 2014/1/4 Chris Vine :
> > Is it efficiency concerns that make you think it unusual, or just
> > that the use case is unusual?
>
> I don't think that creating a new module is particularly inefficient,
> and it would only become noticab
2014/1/4 Chris Vine :
> Is it efficiency concerns that make you think it unusual, or just that the
> use case is unusual?
I don't think that creating a new module is particularly inefficient,
and it would only become noticable if you were creating many many
threads with a short lifetime. What's un
Chris Vine writes:
> Unfortunately, from what Mark Weaver says, the module system doesn't
> initialize itself in a thread safe way either :(.
That's not quite right. It initializes itself in a thread safe way.
However, _after_ initialization, it does not load modules in a thread
safe way.
> Tha
On Sat, 04 Jan 2014 14:37:59 -0500
Mark H Weaver wrote:
> Indeed, top-level bindings are always looked up in the "current
> module". Each thread has its own "current module", but
> 'scm_with_guile' initially sets the current module to (guile-user).
> That's usually desirable, because you may have
Panicz Maciej Godek writes:
> 2014/1/4 Chris Vine :
>> It seems as if top level variables in code evaluated by scm_c_eval_string()
>> are shared between concurrently running threads. Is this really the
>> intended behaviour (it is a significant and unexpected usability
>> restriction)? Maciej (
On Sat, 04 Jan 2014 01:00:46 +0100
l...@gnu.org (Ludovic Courtès) wrote:
> Chris Vine skribis:
>
> > I am having problems using libguile in a multi-threaded environment,
> > which boils down to the following small test case, which fails with
> > a segmentation fault with guile-2.0.9:
> >
> > #inc
On Sat, 4 Jan 2014 16:01:35 +0100
Panicz Maciej Godek wrote:
[snip]
> It indeed does seem that the threads share their top-level bindings on
> guile's side, and I suppose that this is the intended behaviour. I
> think that it can be easily adjusted with scm_eval_string_in_module,
> i.e. if you pro
Hi,
Chris Vine skribis:
> I am having problems using libguile in a multi-threaded environment,
> which boils down to the following small test case, which fails with a
> segmentation fault with guile-2.0.9:
>
> #include
> #include
>
> void *guile_wrapper (void *data) {
> scm_c_eval_string ("(
2014/1/4 Chris Vine :
> There is something even more bizarre than as reported in the exchange
> with Maciej. The further test case below prints:
>
> Hello
> 20
> 20
>
> I would have expected:
>
> Hello
> 10
> 20
>
> It seems as if top level variables in code evaluated by scm_c_eval_str
On Fri, 03 Jan 2014 20:59:16 -0500
Mark H Weaver wrote:
> Chris Vine writes:
> > I am having problems using libguile in a multi-threaded environment,
> > which boils down to the following small test case, which fails with
> > a segmentation fault with guile-2.0.9:
>
> I've recently noticed that
On Fri, 03 Jan 2014 20:59:16 -0500
Mark H Weaver wrote:
> Chris Vine writes:
> > I am having problems using libguile in a multi-threaded environment,
> > which boils down to the following small test case, which fails with
> > a segmentation fault with guile-2.0.9:
>
> I've recently noticed that
On Sat, 4 Jan 2014 02:22:11 +0100
Panicz Maciej Godek wrote:
> I concluded that this might be a solution. I tested it with 2.0.5 from
> ubuntu repository. I had to add GC_allow_register_threads (and link
> against gc, accordingly), because otherwise the program aborted with
> the message "Threads
12 matches
Mail list logo