use UniqSupply in FastString?

Nicolas Frisby nicolas.frisby at gmail.com
Sat Jul 6 19:13:48 CEST 2013


On Sat, Jul 6, 2013 at 1:48 AM, Simon Marlow <marlowsd at 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
> getOrSetGHCConcSignalSignalHan**dlerStore.  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 <ghc-devs-bounces at haskell.org>
>> [mailto:ghc-devs-bounces@**haskell.org <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<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.
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/ghc-devs/attachments/20130706/9a035197/attachment.htm>


More information about the ghc-devs mailing list