On Sat, Jul 6, 2013 at 1:48 AM, Simon Marlow <[email protected]> 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 <[email protected]> >> [mailto:ghc-devs-bounces@**haskell.org <[email protected]>] >> *On Behalf Of *Nicolas Frisby >> *Sent:* 05 July 2013 18:14 >> *To:* [email protected] >> *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. >> >> >
_______________________________________________ ghc-devs mailing list [email protected] http://www.haskell.org/mailman/listinfo/ghc-devs
