use UniqSupply in FastString?

[Simon Marlow]

I haven't been following this in detail, but I think you're encountering 
the same problem we had with various top-level IORefs in the base 
package.  The solution we have there is grotesque but it works.  Take a 
look at libraries/base/GHC/Conc/Signal.hs, search for
getOrSetGHCConcSignalSignalHandlerStore.  There is some corresponding 
RTS gunk to help with this in rts/Globals.c.

We can't make FastString use UniqSupply - it must use unsafePerformIO, 
since the whole point is to hide the side effects behind a nice pure API.

Cheers,
	Simon


On 06/07/13 00:03, Simon Peyton-Jones wrote:
> A UniqSupply has a single shared Int behind the scenes, so it’s really
> no different.
>
> Simon Marlow may want to comment on your proposed solutions. Personally
> I think Option 1 is most attractive. Yes, the API changes, but in a
> decent way and one that may be useful for other things.
>
> Now I think of it, why can’t ‘install’ do the workAroundGloblals call?
> Then clients would not need to.  Maybe I’m not thinking straight
>
> Simon
>
> *From:*ghc-devs-bounces at haskell.org
> [mailto:ghc-devs-bounces at haskell.org] *On Behalf Of *Nicolas Frisby
> *Sent:* 05 July 2013 18:14
> *To:* ghc-devs at haskell.org
> *Subject:* use UniqSupply in FastString?
>
> Does it sound reasonable to change the FastString module to use a
> UniqSupply instead of using that Int for generating uniques?
>
> I've been trying to let a statically-linked compiler shares its
> FastString table with plugins. Status, background info, options here:
>
> http://hackage.haskell.org/trac/ghc/wiki/Plugins/ReinitializeGlobals
>
> (I got a little ahead of myself with Option 2…)
>
> Uniques for FastStrings are currently allocated linearly using a global
> Int variable. Because unsafePerformIO is used, it's difficult to keep
> the two global Ints in synch (one for the compiler, the other for the
> plugins). The danger is that the compiler and a plugin might allocate
> the same unique for distinct FastStrings — that'd break a major
> invariant. If we used UniqSupply, we'd avoid that danger, just about for
> free.
>
> I'm not sure how robust/speedy UniqSupply is though. Considering its
> widespread use, I figured it'd be good enough by a pretty wide margin;
> FastString *creation* seems relatively infrequent.
>
> Thanks for your input.
>