Make StaticPtr (more) robust to code changes and recompilation
Discussion migrated from this thread on Reddit.
The documentation for GHC.StaticPtr states that "Only processes launched from the same program binary are guaranteed to use the same set of keys."
On the other hand, this blog post by Simon suggests that the only sensible implementation of StaticPtr would be as (essentially) a package/module/identifier name triple, which sounds right to me. In this case two StaticPtrs should share the same key as long as they are in the same package/module and assigned to the same identifier.
My use case is similar to the one described here, where StaticPtr is used for (de)serialization of an existential. As pointed out in the comments to that post, this approach could break upon any recompilation of the code base.
Having static pointers stable only across instances of the same binary also seems like it would be a potential problem for the applications like CloudHaskell that StaticPointers was developed for. Presumably this means means all nodes need to be based on the same architecture and updates need to happen on every node simultaneously.
Trac metadata
| Trac field | Value |
|---|---|
| Version | 8.4.3 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | Edsko, Facundo |
| Operating system | |
| Architecture |