guile-user
[Top][All Lists]
Advanced

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

Re: libguile thread safety


From: Mark H Weaver
Subject: Re: libguile thread safety
Date: Sun, 05 Jan 2014 12:37:29 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

Panicz Maciej Godek <address@hidden> writes:

> 2014/1/5 Chris Vine <address@hidden>:
>
>> 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" syntax (or others, like
> "resolve-module", if you are planning to use them) to make sure that
> it is thread safe.
>
> The sole act of redefinition would require you to create a new module like 
> this:
> (define-module (safe-modules)
>   #:use-module (ice-9 format)
>   #:replace ((safe-use-modules . use-modules)))
>
> (define-syntax-rule (safe-use-modules modules ...)
>   (begin
>     (format #t "loading modules ~a... " '(modules ...))
>     (use-modules modules ...)
>     (format #t "done!\n")))
>
> You'd need to replace the the messages with some thread
> synchronization mechanism, to make sure that if one thread calls
> "use-modules", all the others that would try to do that at that time
> would have to wait.

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' at all.  In fact, a module is autoloaded the first
time 'scm_c_eval_string' is called.  Also, there are potential
deadlocks.

We should just fix the problem properly, and that's what I intend to do.

     Mark



reply via email to

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