Re: libguile thread safety

[Panicz Maciej Godek]

2014/1/4 Chris Vine <address@hidden>:
> 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 unusual (and I think that Mark
would agree) is that you'd normally want your thread to be able to
access all the definitions that are visible to the program (or: to the
main thread). If a program is written in a functional style, the
threads usually don't mutate their global environment -- they just
read the definitions -- so any race conditions or other conflicts are
unlikely.

I think that your use-case is different and that you make very few
assumptions on the code that the threads will execute -- in
particular, that it might be a highly imperative code which does
mutate its global state. If it is so, then I think that this is the
right way. (Be warned, that it doesn't protect the system from
malicious code -- it is still possible for a thread to modify the
content of another module, but it's difficult to do that by accident)

> make-fresh-user-module is not documented.  It might be worth adding it
> to the documentation.

it definitely might ;)