Re: [GHC] #910: --make should have a -j flag for parallel building

#910: --make should have a -j flag for parallel building -------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: feature request | Status: patch Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.4.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Unknown/Multiple Type of failure: None/Unknown | Difficulty: Unknown Test Case: N/A | Blocked By: Blocking: | Related Tickets: -------------------------------------+------------------------------------ Comment (by parcs): nh2: That's an interesting idea. We would just have to persist the timing information somehow (through the interface file maybe) and implement a smart semaphore (replacing QSem) that wakes up the module that would result in the shortest compile time. It certainly ''sounds'' possible, at least. Simon: Import loops were indeed not handled correctly. I managed to work out a solution that I hope is understandable. It involves augmenting a module's explicit textual dependencies with the implicit dependencies that arise from module loops. Let me know what you think. Other changes I made: 1. removed the `BinIO` constructor as suggested 2. more thoroughly commented the `FastString` implementation, as suggested. 3. revised one of the thread-safety changes: originally, I changed `newUnique` and `newUniqueSupply` to atomically update the `env_us` var. But the only reason this was necessary is because the `env_us` var was shared among interleaved threads created by `forkM`. So instead of making sure to atomically update this var, I think it is more sensible to not share the `env_us` var among interleaved threads. This solution should be in theory more efficient as well, as multiple threads are no longer potentially contending on the same `env_us` var. 4. and I enabled buffering of stdout/stderr when compiling modules via GHCi Please perform a second pass on all the commits, as I did a lot of rebasings and fixups etc and I might have missed something stupid. I have not yet fixed the IO manager bug. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/910#comment:31 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler
participants (1)
-
GHC