[Haskell-cafe] Re: [Haskell] Top Level <-
ashley at semantic.org
Sat Aug 30 09:13:18 EDT 2008
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.
Currently we have shared memory should be raw bytes, and IORef values
can't be serialised there.
> 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.
IORefs cannot be serialised, so they cannot be sent over serialised RPC.
So let us consider your shared memory possibility.
Do you mean simply an IORef of a block of bytes of the shared memory?
That would be fine, but that is really a different type than IORef. It
still keeps the "global scopes" separate, as IORefs cannot be passed
Or do you mean you could use shared memory to pass across IORefs? This
would mean joining the address spaces with no memory protection between
them. It would mean joining the garbage collectors somehow. Once you've
dealt with that, the issue of making sure that each initialiser runs
only once for the new shared space is really only one more issue.
More information about the Haskell-Cafe