Digging into the guts of spawn' and removing the pipes-concurrency shell, I
boiled the behaviour change down to this:
import Control.Concurrent.STM
import Data.IORef
main :: IO ()
main = do
sealed <- atomically $ newTVar False
rRecv <- newIORef ()
mkWeakIORef rRecv (atomically $ writeTVar sealed True)
atomically $ do
b <- readTVar sealed
check b
return ()
So definitely a weak IO reference/TVar interaction effect (and nothing to
do with unsafePerformIO)
On Sunday, August 17, 2014 7:21:03 AM UTC+10, Gabriel Gonzalez wrote:
>
> The only progress I made was to start this thread on the ghc-users
> mailing list:
>
>
> http://www.haskell.org/pipermail/glasgow-haskell-users/2014-July/025107.html
> <http://www.google.com/url?q=http%3A%2F%2Fwww.haskell.org%2Fpipermail%2Fglasgow-haskell-users%2F2014-July%2F025107.html&sa=D&sntz=1&usg=AFQjCNGDk736dGjt1ehxZsRLDAzXZzzF6g>
>
> The #1 issue I have is that it's not clear what changed in the transition
> from ghc-7.6 to ghc-7.8 that caused this problem. I think if we understood
> that we can better understand the potential solutions.
>
> The worst case scenario (if the problem is can't be resolved) is that I
> just change the type of `spawn` to:
>
> spawn :: Buffer a -> Managed (Output a, Input a, STM ())
>
> ... where that will automatically `seal` the action when done. It's not
> as useful, but at least it will avoid the exception.
>
> On 8/16/14, 2:14 PM, Tony Day wrote:
>
> Any progress on this Gabe?
>
> I was thinking of diving in and exploring weak references if no immediate
> solution has presented itself.
>
> Knowing absolutely zero about them, to what extent could I apply
> equational reasoning to the minimum code, given the effects in there?
>
> I took the liberty of adding this as an open issue on github.
>
> On Monday, July 14, 2014 5:04:48 AM UTC+10, Gabriel Gonzalez wrote:
>>
>> Alright, so even when I switched to the safe `mkWeakTVar` I still see
>> the exact same issue. I've also reduced the minimal reproducing program to:
>>
>> import Pipes.Concurrent
>>
>> main = do
>> (_, input) <- spawn Unbounded
>> atomically $ recv input
>>
>> It seems like something has fundamentally changed about how weak
>> references interact with STM transactions in ghc-7.8. Right now I am
>> trying to see if there is some other way to accomplish the same behavior
>> without weak references.
>>
>> On 7/7/14, 3:53 PM, Michael Thompson wrote:
>>
>> The bit about user input was nonsense; the example wasn't using the
>> `user` it defined. Here is a more minimal main (with the same `worker`):
>>
>> main = do
>> (output, input) <- spawn (Bounded 1)
>> a1 <- async $ runEffect $ fromInput input >-> worker 1
>> a2 <- async $ runEffect $ yield 1 >-> toOutput output
>> wait a1
>> wait a2
>>
>> $ ./work
>> Worker #1: Processed 1
>> work: thread blocked indefinitely in an STM transaction
>>
>> It works if a higher `Bounded` or if `Unbounded` is chosen; it works if
>> the second `wait` is dropped, etc.
>> The most striking difference was the use of `Unbounded` in the good
>> version and `Bounded` in the separate module.
>>
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "Haskell Pipes" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to [email protected].
>> To post to this group, send email to [email protected].
>>
>>
>> --
> You received this message because you are subscribed to the Google Groups
> "Haskell Pipes" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected] <javascript:>.
> To post to this group, send email to [email protected]
> <javascript:>.
>
>
>
--
You received this message because you are subscribed to the Google Groups
"Haskell Pipes" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
