use UniqSupply in FastString?
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.
> 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
>> *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:
>> (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
>> 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...
More information about the ghc-devs