
Hello Lennart, Sunday, September 23, 2007, 8:30:43 PM, you wrote: and GHC stops executing this thread - wise solution. but it can't decide whether some signal handlers/backcalls are established and so whther are program definitely will never finish or not
But this was a very particular case when a thread starts evaluating a node and then comes back to the same node again. The general case is (of course) undecidable.
On 9/23/07, Bulat Ziganshin
wrote: Hello Lennart,
Sunday, September 23, 2007, 2:05:46 PM, you wrote:
i bet that general case contains too much conditions to check. program may be unblocked by other thread, by OS signal, by I/O operation completion, by C thread. how for example RTS can check that we have started I/O operation with completion callback which will call abort() function?
I agree. This situation is totally detectable.
On 9/23/07, Neil Mitchell
wrote: Hi
I'm not sure, but since it would require the detection of an evaluation that does not terminate,it comes down to the halting problem, which is not generally solvable. Maybe the experts can confirm my intuition?
I think your intuition is off. This isn't the problem of detecting that a computation might not halt, its a question of detecting after the fact a very restricted case of non-termination has occurred. I think it should be possible to assign threads etc to these things, but may make the code run slower in the common case.
Thanks
Neil _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
-- Best regards, Bulat mailto:Bulat.Ziganshin@gmail.com