Opened 14 months ago

Last modified 9 months ago

#15395 new feature request

Make StaticPtr (more) robust to code changes and recompilation

Reported by: richardw Owned by:
Priority: normal Milestone: 8.10.1
Component: Compiler Version: 8.4.3
Keywords: StaticPointers Cc: Facundo, Edsko
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:


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.

Change History (3)

comment:1 Changed 14 months ago by bgamari

Keywords: StaticPointers added

comment:2 Changed 14 months ago by bgamari


These won't be fixed for in GHC 8.6.

comment:3 Changed 9 months ago by osa1


Bumping milestones of low-priority tickets.

Note: See TracTickets for help on using tickets.