> I have two bug reports related to using the Concurrent
> module in GHCi (I am running 5.02 on Solaris).
>
> 1)
>
> I get the following behavior:
>
> Main> forkIO (print "1")
> Main> forkIO (print "2" >> print "3")
> "1"
> Main> print "4"
> "2"
> "4"
> "3"
>
> It seems that GHCi returns to the prompt when the main
> thread has stopped, even when there are still other threads
> running. The bug is that those other threads might then be
> later executed, completely arbitrarily.
>
> Wouldn't it make more sense to return to the prompt when all
> threads have finished?
The behaviour is consistent with what happens in a standalone program:
only the main thread is required to terminate in order for the program
as a whole to terminate.
I don't think it would be easy to change this behaviour, because the RTS
doesn't have a handle on which threads were forked by the user
computation and which belong to the system.
> 2)
>
> GHCi terminates with "no threads to run: infinite loop
> or deadlock?" when doing this:
>
> Main> newEmptyMVar >>= takeMVar
> ghc-5.02: no threads to run: infinite loop or deadlock?
>
> The error message is nice, but I would expect to get back to
> the prompt.
This is a result of the fact that we don't sandbox the computation very
well - in fact, the computation is just run in the main GHCi thread, so
when this thread deadlocks the whole system has to fall over.
It is possible to start a completely new main thread for each
evaluation, so that deadlock could be detected, by recursively invoking
the RTS from within GHCi to evaluate the computation. I might have a go
at doing this.
Cheers,
Simon
_______________________________________________
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
