Re: libguile thread safety

[Chris Vine]

On Sat, 4 Jan 2014 23:43:22 +0100
Panicz Maciej Godek <address@hidden> wrote:
> 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)

The problem here isn't so much deliberate mutation of data, as top level
name clashes causing silent unwanted mutation.

But yes, in this usage task isolation is a positive virtue, not
something to be regretted.  We can assume no malicious intent (the
house-keeping of any thread pool can be wrecked by the simple expedient
of a task calling pthread_exit(): one must assume some competence and
good faith on the part of the programmer).  One purpose of top level
variables at the module level here is to pass arguments to loaded scheme
files.

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.

Chris