Open gbaz opened 6 years ago
The keys in the remote table are more stable across builds than static pointers. There might be use cases where this matters. That's the only concern I'm aware of.
Hmmm. Would be really interesting to see how this will affect the rest of cloud haskell libraries... Do we have a lot of folks that require compatibility with earlier versions of ghc?
Hi, I am not a distributed-haskell / Cloud Haskell user, but I found this package when looking around for anything that could effectively perform automatic defunctionalisation, since I want to be able to suspend execution, serialise the state, potentially send it elsewhere, and resume it. For a complex program this often means I have to be able to serialise a closure, that was stored e.g. for a Promise or a continuation or something.
One nice consequence of having more stable names, is you can suspend execution state, then upgrade your code, and then resume your execution from the same state, but now running e.g. a bugfixed version of a closure. So even if nobody is using this today, I'd like to voice my support in keeping this feature for this reason - or else forking this library and retaining this feature, for general non-Cloud-Haskell users - I think it's a useful feature that someone could want some day.
I was actually a bit surprised to find that GHC's own implementation of static pointers does not have this property - on http://hackage.haskell.org/package/base/docs/GHC-StaticPtr.html it says "Only processes launched from the same program binary are guaranteed to use the same set of keys" which IMO is hugely restrictive, although perhaps it makes low-level implementation easier. So it seems this library is a good high-level wrapper around that, that provides stability of RemoteTable
keys.
(This restriction is somewhat clear from the code - GHC.StaticKey is an alias for GHC.Fingerprint.Type.Fingerprint which is two Word64
presumably globally-generated by the compiler via some opaque algorithm.)
The new minimum GHC version is 8.10 (base 4.14), which has support for StaticPtr
.
I might get to this eventually, but I am also happy to review pull requests
Now that there are proper static pointers in ghc, is the remotetable necessary, or can it just be eliminated?