On Sat, 30 Aug 2008, Ashley Yakeley wrote:
Ganesh Sittampalam wrote:
Firstly, that's a property of the current implementation, rather than a
universal one, IMO. I don't for example see why you couldn't add a
newIORef variant that points into shared memory, locking issues aside.
OK, so that would be a new Haskell feature. And it's that feature that
would be the problem, not top-level <-. It would bring its own garbage
collection issues, for instance.
OK, never mind about that; I agree it's not a very good idea. An IORef
shouldn't escape the scope of the RTS/GC that created it.
Also, the issue is not whether you can *use* them across multiple
processes, but whether they are unique across multiple processes.
Uniqueness has two possible definitions; aliasing, and representational
equality. No two IORefs will ever alias, so by that definition they exist
at global scope. For representational equality, that exists at least at
process scope, and perhaps more.
By global scope, I mean the largest execution scope an IORef created by
newIORef can have. Each top-level IORef declaration should create an IORef
at most once in this scope.
That's a reasonable definition, if by "execution scope" you mean your
previous definition of "where the IORef can be directly used". But it's
not process scope; two independent Haskell libraries in the same process
can no more share IORefs than two separate Haskell processes.
[what I meant by global scope above was "the entire world"]
Ganesh
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
