Skip to content
Snippets Groups Projects

Make StaticPtr (more) robust to code changes and recompilation

    • Open Issue created by richardw @trac-richardw

    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
    To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information

    Child items 0

    • No child items are currently assigned. Use child items to break down this issue into smaller parts.

    Activity

    Please register or sign in to reply