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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED] > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Best regards, Bulat mailto:[EMAIL PROTECTED] _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe