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