On Sat, 4 Jan 2014 23:43:22 +0100 Panicz Maciej Godek <[email protected]> wrote: > 2014/1/4 Chris Vine <[email protected]>: > > 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
