On Tue, 18 Mar 2014 11:22:13 -0400
Mark H Weaver wrote:
> Chris Vine writes:
>
> > Has thread-safe module loading turned out to be too difficult to
> > do, or is it still something that is likely to happen in the future?
>
> I consider this to be an important issue, and I still intend to fix
>
Chris Vine writes:
> Has thread-safe module loading turned out to be too difficult to do, or
> is it still something that is likely to happen in the future?
I consider this to be an important issue, and I still intend to fix it.
However, fixing it in such a way that I could confidently believe w
On Sun, 05 Jan 2014 12:37:29 -0500
Mark H Weaver wrote:
[snip]
> This wouldn't work. First of all, 'use-modules' is a macro, not a
> procedure, but more importantly, modules are autoloaded in many places
> deep in the guts of the system. Notice that Chris' test cases didn't
> use 'use-modules' a
Panicz Maciej Godek writes:
> 2014/1/5 Chris Vine :
>
>> I actually have a prototype working well now, apart from the module
>> issue Mark Weaver referred to, which I have to say has not yet bitten me
>> but no doubt might.
>
> If you are worried about this, you could try to take your own
> preca
2014/1/5 Chris Vine :
> I actually have a prototype working well now, apart from the module
> issue Mark Weaver referred to, which I have to say has not yet bitten me
> but no doubt might.
If you are worried about this, you could try to take your own
precautions and redefine the "use-modules" syn
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
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 the module loading process in Guile is not
thread safe. I hope to fi
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 explicit registering is not previously enabled"
whenever it attempted
The code looks fine to me. It seems that there's a bug in guile --
when I insert one second sleep between the two invocations of
pthread_create, everything works fine. However, when I go down with
the sleep time below ~5 microseconds, things are getting weird.
The good news is that the problem
On Sat, 4 Jan 2014 01:08:12 +0100
Panicz Maciej Godek wrote:
> Hi,
> I have never used the pthread library directly, but would it be
> possible for your program to use scm_spawn_thread instead? (according
> to the manual, it starts a new thread in guile mode, but I guess it
> needs to be run in gu
Hi,
I have never used the pthread library directly, but would it be
possible for your program to use scm_spawn_thread instead? (according
to the manual, it starts a new thread in guile mode, but I guess it
needs to be run in guile mode as well)
22 matches
Mail list logo
