Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Can we remove RemoteTable? #402

Open
gbaz opened this issue Jul 25, 2018 · 4 comments
Open

Can we remove RemoteTable? #402

gbaz opened this issue Jul 25, 2018 · 4 comments

Comments

@gbaz
Copy link

gbaz commented Jul 25, 2018

Now that there are proper static pointers in ghc, is the remotetable necessary, or can it just be eliminated?

@facundominguez
Copy link
Contributor

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.

@hyperthunk
Copy link
Member

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?

@infinity0
Copy link

infinity0 commented Apr 6, 2020

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.)

@LaurentRDC LaurentRDC transferred this issue from haskell-distributed/distributed-static Sep 3, 2024
@LaurentRDC
Copy link
Member

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants