Re: [GHC] #5865: threadDelay is disrupted by system clock changes

2012-04-09 Thread GHC 
#5865: threadDelay is disrupted by system clock changes
-+--
Reporter:  joeyadams |   Owner:  pcapriotti 
Type:  bug   |  Status:  patch  
Priority:  high  |   Milestone:  7.4.2  
   Component:  Runtime System| Version:  7.4.1  
Keywords:|  Os:  Unknown/Multiple   
Architecture:  Unknown/Multiple  | Failure:  Incorrect result at runtime
  Difficulty:  Unknown   |Testcase: 
   Blockedby:|Blocking: 
 Related:|  
-+--

Comment(by pcapriotti):

 Replying to [comment:18 joeyadams]:
  I don't think the Win32 patch is thread-safe.  If two OS threads call
 threadDelay simultaneously, it's possible for {{{static}}} variables like
 {{{static HsWord64 previous_count}}} to be invalidated by concurrent
 updates, since the assignment isn't guaranteed to be atomic (to my
 knowledge).

 Right, writes are not atomic. So the initialization of the `frequency`
 variable is broken, too. The latter can be fixed by moving it to some
 global initialization function ('startIOManagerThread`, perhaps?), but I'm
 not sure how the `GetTickCount` accumulator can be fixed. I looked into
 the `Interlocked*` family of functions, but they are only supported from
 XP onwards, which is less then `QueryPerformanceCounter` itself.

 Any suggestions?

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5865#comment:19
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

[GHC] #5995: http://wiki.barrelfish.org/Getting_Started#ghcInstall is what i tried to do

2012-04-09 Thread GHC 
#5995: http://wiki.barrelfish.org/Getting_Started#ghcInstall
is what i tried to do
--+-
 Reporter:  guest |  Owner:
 Type:  bug   | Status:  new   
 Priority:  normal|  Component:  Compiler  
  Version:  6.10.4|   Keywords:
   Os:  Linux |   Architecture:  x86_64 (amd64)
  Failure:  None/Unknown  |   Testcase:
Blockedby:|   Blocking:
  Related:|  
--+-
 hake: panic! (the 'impossible' happened)
   (GHC version 6.10.4 for x86_64-unknown-linux):
 Could not find module `HakeTypes':

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/5995
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #4900: DEPENDS pragma

2012-04-09 Thread GHC 
#4900: DEPENDS pragma
---+
  Reporter:  cdsmith   |  Owner:  
  Type:  feature request   | Status:  patch   
  Priority:  normal|  Milestone:  7.6.1   
 Component:  Build System  |Version:  
Resolution:|   Keywords:  
Os:  Unknown/Multiple  |   Architecture:  Unknown/Multiple
   Failure:  None/Unknown  | Difficulty:  Unknown 
  Testcase:  TH_Depends|  Blockedby:  
  Blocking:|Related:  
---+
Changes (by parcs):

 * cc: patrick@… (added)
  * status:  new = patch


Comment:

 Hi,

 Currently this feature does not work with GHCi, as that has its own
 recompilation  checking for determining whether to pass a module down to
 the standard compilation pipeline.

 I have attached a patch that extends this feature to work GHCi, so that
 modules will be reloaded when their usage files have changed. Overview of
 changes:

  1. A field is added to ModSummary to keep track of the latest
 modification time of the module's usage files (`ms_uf_date`)
  2. When summarising a module/file, `ms_uf_date` is checked for freshness
 and updated if necessary.
  3. A module is now marked unstable if `ms_uf_date` is later than its
 'linkableTime'.

 Is this a reasonable solution?

-- 
Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/4900#comment:43
GHC http://www.haskell.org/ghc/
The Glasgow Haskell Compiler

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs