Hi,
I am working on a library I'd like to release to hackage very soon, but I've
found a problem with supporting GHC 6.12 and GHC 7.0.
Consider the following program:
import Control.Concurrent
import Data.Typeable
main :: IO ()
main =
do { fin1 <- newEmptyMVar
; fin2 <- newEmptyMVar
On Sunday 09 October 2011, 13:52:47, Jean-Marie Gaillourdet wrote:
> This seems to be a Heisenbug as it is extremely fragile, when adding a
> "| grep 1" to the while loop it seems to disappears. At least on my
> computers.
Still produces 1s here with a grep.
>
> All this was done on several Mac
Hi Daniel,
On 09.10.2011, at 14:45, Daniel Fischer wrote:
> On Sunday 09 October 2011, 13:52:47, Jean-Marie Gaillourdet wrote:
>> This seems to be a Heisenbug as it is extremely fragile, when adding a
>> "| grep 1" to the while loop it seems to disappears. At least on my
>> computers.
>
> Still
On Sunday 09 October 2011, 15:30:20, Jean-Marie Gaillourdet wrote:
> Hi Daniel,
>
> On 09.10.2011, at 14:45, Daniel Fischer wrote:
> > On Sunday 09 October 2011, 13:52:47, Jean-Marie Gaillourdet wrote:
> >> This seems to be a Heisenbug as it is extremely fragile, when adding
> >> a "| grep 1" to t
Hi,
the Eq instance of TypeRep shows the same non-deterministic behavior:
import Control.Concurrent
import Control.Exception
import Control.Monad
import Data.Typeable
main :: IO ()
main =
do { fin1 <- newEmptyMVar
; fin2 <- newEmptyMVar
; forkIO $ return (typeOf ()) >>= evaluate >>= pu
Hi Daniel,
On 09.10.2011, at 16:24, Daniel Fischer wrote:
> On Sunday 09 October 2011, 15:30:20, Jean-Marie Gaillourdet wrote:
>> Hi Daniel,
>>
>> On 09.10.2011, at 14:45, Daniel Fischer wrote:
>>> On Sunday 09 October 2011, 13:52:47, Jean-Marie Gaillourdet wrote:
This seems to be a Heise
On 09.10.2011, at 16:40, Jean-Marie Gaillourdet wrote:
> I will report a bug.
http://hackage.haskell.org/trac/ghc/attachment/ticket/5540/
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/
Jean-Marie Gaillourdet:
> the Eq instance of TypeRep shows the same non-deterministic behavior:
Of course, equality on TypeReps is implemented by comparison of the Keys.
On Sunday 09 October 2011, 16:40:13, Jean-Marie Gaillourdet wrote:
> Hi Daniel,
> I've been chasing the source of the non-dete
Hi,
On 09.10.2011, at 17:27, Daniel Fischer wrote:
> Jean-Marie Gaillourdet:
>> the Eq instance of TypeRep shows the same non-deterministic behavior:
>
> Of course, equality on TypeReps is implemented by comparison of the Keys.
>
> On Sunday 09 October 2011, 16:40:13, Jean-Marie Gaillourdet wro
Hi,
On 09.10.2011, at 17:37, Jean-Marie Gaillourdet wrote:
> Hi,
>
> On 09.10.2011, at 17:27, Daniel Fischer wrote:
>
>> That's what I expect.
>> I think what happens is:
>>
>> -- from Data.Typeable
>>
>> cache = unsafePerformIO $ ...
>>
>>
>> mkTyConKey :: String -> Key
>> mkTyConKey str
Quoting Jean-Marie Gaillourdet :
That sounds plausible. Do you see any workaround? Perhaps repeatedly
evaluating typeOf?
If there's a concurrency bug, surely the workaround is to protect
calls to the non-thread-safe function with a lock.
typeOfWorkaround lock v = do
() <- take
On 09.10.2011, at 17:56, wagne...@seas.upenn.edu wrote:
> Quoting Jean-Marie Gaillourdet :
>
>> That sounds plausible. Do you see any workaround? Perhaps repeatedly
>> evaluating typeOf?
>
> If there's a concurrency bug, surely the workaround is to protect calls to
> the non-thread-safe funct
On Sunday 09 October 2011, 17:51:06, Jean-Marie Gaillourdet wrote:
> > That sounds plausible. Do you see any workaround? Perhaps repeatedly
> > evaluating typeOf?
>
> typeOf' seems to be a working workaround:
>
> typeOf' val
> | t1 == t2 = t1
> | otherwise = typeOf' val
> where
> t
On 09.10.2011, at 18:13, Daniel Fischer wrote:
> On Sunday 09 October 2011, 17:51:06, Jean-Marie Gaillourdet wrote:
>>> That sounds plausible. Do you see any workaround? Perhaps repeatedly
>>> evaluating typeOf?
>>
>> typeOf' seems to be a working workaround:
>>
>> typeOf' val
>>| t1 == t2
On Sun, Oct 09, 2011 at 03:30:20PM +0200, Jean-Marie Gaillourdet wrote:
Hi Daniel,
On 09.10.2011, at 14:45, Daniel Fischer wrote:
On Sunday 09 October 2011, 13:52:47, Jean-Marie Gaillourdet wrote:
This seems to be a Heisenbug as it is extremely fragile, when adding a
"| grep 1" to the while l
October 2011 12:53
To: glasgow-haskell-users
Subject: Is this a concurrency bug in base?
Hi,
I am working on a library I'd like to release to hackage very soon, but I've
found a problem with supporting GHC 6.12 and GHC 7.0.
Consider the following program:
import Control.Concurr
.org
[mailto:glasgow-haskell-users-boun...@haskell.org] *On Behalf Of
*Jean-Marie Gaillourdet
*Sent:* 09 October 2011 12:53
*To:* glasgow-haskell-users
*Subject:* Is this a concurrency bug in base?
Hi,
I am working on a library I'd like to release to hackage very soon, but
I've found a proble
Hi,
I've continued my search for a proper workaround. Again, I did find some
unexpected results. See below.
On 09.10.2011, at 17:56, wagne...@seas.upenn.edu wrote:
> Quoting Jean-Marie Gaillourdet :
>
>> That sounds plausible. Do you see any workaround? Perhaps repeatedly
>> evaluating typeO
: wagne...@seas.upenn.edu; Daniel Fischer
Cc: glasgow-haskell-users@haskell.org
Subject: Re: Is this a concurrency bug in base?
Hi,
I've continued my search for a proper workaround. Again, I did find some
unexpected results. See below.
On 09.10.2011, at 17:56, wagne...@seas.upenn.edu
Jean-Marie Gaillourdet wrote:
> This is my previous program with your workaround, it is also attached as
> TypeRepEqLock.hs
>
[snip]
> Compile and execute:
>
> $ ghc-7.0.3 -threaded -rtsopts TypeRepEqLock.hs
>
> $ while true ; do ./TypeRepEqLock +RTS -N ; done
> Ok
> Ok
> Ok
> Ok
> Ok
> Ok
> Ok
Hi Simon,
On 12.10.2011, at 10:34, Simon Peyton-Jones wrote:
> Did you try 7.2? As I mentioned, the issue should have gone away entirely
> because there is no shared cache any more
Yes, I did test it with GHC 7.2. And yes, with GHC 7.2 typeOf is fine. I
continued to look into that issue bec
Hi Bertram,
On 12.10.2011, at 13:24, Bertram Felgenhauer wrote:
> This has nothing to do with Data.Typeable though - it appears to be some
> interaction between unsaferPerformIO and MVars that I do not understand.
> The following program occasionally terminates with "thread blocked
> indefinitely
On 12/10/2011 12:24, Bertram Felgenhauer wrote:
Jean-Marie Gaillourdet wrote:
This is my previous program with your workaround, it is also attached as
TypeRepEqLock.hs
[snip]
Compile and execute:
$ ghc-7.0.3 -threaded -rtsopts TypeRepEqLock.hs
$ while true ; do ./TypeRepEqLock +RTS -N ; do
Simon Marlow wrote:
> >import Control.Concurrent
> >import Control.Exception
> >import Control.Monad
> >import System.IO.Unsafe
> >
> >main :: IO ()
> >main = do
> > -- evaluate lock -- adding this line fixes the problem
> >
> > fin1<- newEmptyMVar
> > fin2<- newEmptyMVar
> >
> > fo
24 matches
Mail list logo
