Peter Verswyvelen wrote:
http://www.haskell.org/ghc/docs/2.10/users_guide/user_146.html
http://www.haskell.org/ghc/docs/2.10/users_guide/user_146.htmlseems
to confirm that?
Ouch.
Would it be possible to somehow prevent this behavious? (E.g., by
somehow annotating each black hole with
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?
Andrew Coppin wrote:
Peter Verswyvelen 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
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
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
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
Neil Mitchell wrote:
I think your intuition is off. This isn't the problem of detecting
Oh well, that happens when I try to help people when I don't really know
what I'm talking about ;-)
I though it was impossible to detect a deadlock (and a blackhole is
something like a deadlock no?)
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
Peter Verswyvelen wrote:
I though it was impossible to detect a deadlock (and a black hole is
something like a deadlock no?) *before* it occurred, but in this
case, we're talking about detecting it *when* it occurs, no? And
then raising an error instead of just blocking?
Generally, it's not
Miguel Mitrofanov wrote:
A deadlock happens whenever two (or more) threads are blocked on each
other. Deadlocks can be extremely hard to detect, especially if they
occur intermittently.
Isn't that so much different from garbage collection? Replace
thread with chunk of data, and waits for
Hi,
if I define:
f = f
and then try to evaluate 'f' in GHCi, as one would expect, the interpreter
never returns an answer.
The funny thing is that, while it is stuck in an infinite loop, GHCi doesn't
seem to use any CPU time at all.
How is this possible?
Thanks
titto
Hi
f = f
and then try to evaluate 'f' in GHCi, as one would expect, the interpreter
never returns an answer.
The funny thing is that, while it is stuck in an infinite loop, GHCi doesn't
seem to use any CPU time at all.
It's called a black hole. The runtime can detect that f directly
On Saturday 22 September 2007 10:58:49 Neil Mitchell wrote:
Hi
f = f
and then try to evaluate 'f' in GHCi, as one would expect, the
interpreter never returns an answer.
The funny thing is that, while it is stuck in an infinite loop, GHCi
doesn't seem to use any CPU time at all.
Gotta love lazy infinite loops :-D
Sounds like something out of a Douglas Adams novel.
Ok, this post is totally off-topic...
On 9/22/07, Pasqualino 'Titto' Assini [EMAIL PROTECTED] wrote:
The funny thing is that, while it is stuck in an infinite loop, GHCi
doesn't seem to use any CPU time
I guess you entered a black hole! :-)
The problem is that don't understand black holes myself, I just got
introduced with the same thing yesterday :-) I confused me a lot too.
The only explanation I could give you intuitively is that GHCi is
running in multi threaded execution mode, and that
Peter Verswyvelen wrote:
http://www.haskell.org/ghc/docs/2.10/users_guide/user_146.html
http://www.haskell.org/ghc/docs/2.10/users_guide/user_146.htmlseems to
confirm that?
Oops, sorry, these seems to be docs for Concurrent Haskell... But maybe
the experts can confirm if the principle
On Sat, Sep 22, 2007 at 12:58:12PM +0200, Peter Verswyvelen wrote:
Peter Verswyvelen wrote:
http://www.haskell.org/ghc/docs/2.10/users_guide/user_146.html
http://www.haskell.org/ghc/docs/2.10/users_guide/user_146.htmlseems to
confirm that?
Oops, sorry, these seems to be docs for
17 matches
Mail list logo
