On Sat, Jul 6, 2013 at 1:48 AM, Simon Marlow <marlowsd@gmail.com> wrote:

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.

Excellent. Thanks very much. This the most robust solution I envisioned, but I didn't know enough about the low-level stuff to execute. I'm excited to work through the code.

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.

tl;dr The rest of my reply is moot, since your RTS workaround is preferred.

I should have been clearer: I meant to use unsafePerformIO-around-a-UniqSupply instead of using unsafePerformIO-around-a-linearly-incremented-Int. The intent was to handle a well-behaved coarse interleaving of the compiler and plugin — as opposed to parallel execution or fine-grain concurrency.

Thus, switching to unsafePerformIO-around-a-UniqSupply seemed at least as "safe" as the current Int implementation, but with the splitting logic. Are there any pitfalls in that logic?

Thanks again for the spot-on pointer.

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@haskell.org
[mailto:ghc-devs-bounces@haskell.org] *On Behalf Of *Nicolas Frisby
*Sent:* 05 July 2013 18:14
*To:* ghc-devs@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.