Re: libguile thread safety

2014-01-04 Thread Chris Vine
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

Re: libguile thread safety

2014-01-04 Thread Panicz Maciej Godek
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

Re: libguile thread safety

2014-01-04 Thread Mark H Weaver
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

Re: libguile thread safety

2014-01-04 Thread Chris Vine
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

Re: libguile thread safety

2014-01-04 Thread Mark H Weaver
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 (

Re: libguile thread safety

2014-01-04 Thread Chris Vine
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

Re: libguile thread safety

2014-01-04 Thread Chris Vine
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

Re: libguile thread safety

2014-01-04 Thread Ludovic Courtès
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 ("(

Re: libguile thread safety

2014-01-04 Thread Panicz Maciej Godek
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

Re: libguile thread safety

2014-01-04 Thread Chris Vine
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

Re: libguile thread safety

2014-01-04 Thread Chris Vine
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

Re: libguile thread safety

2014-01-04 Thread Chris Vine
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