The bugs that we have identified result in deadlocks - the runtime doesn't
notice that a thread blocked in throwTo can continue. I can't think of a
way that this could lead to bogus loop, but I suppose I wouldn't be too
surprised if it were possible.
The best way forward is for you to test
Hi Simon,
That's great news. Please let me know when there's a build I can grab, and
I'll try it out.
Regards, - Conal
On Wed, Jan 7, 2009 at 7:22 AM, Simon Marlow marlo...@gmail.com wrote:
The bugs that we have identified result in deadlocks - the runtime doesn't
notice that a thread
Ian Lynagh wrote:
On Mon, Dec 29, 2008 at 05:07:22PM +0100, Bertram Felgenhauer wrote:
Simon Peyton-Jones wrote:
This is odd (to me). The permanently bound stuff applies only to
*synchronous* exceptions, which thread-killing is not. Simon M will
have more to say when he gets back
This is
Conal Elliott wrote:
Indeed -- many thanks to Bertram, Sterling, Peter others for the
help! I think getting this bug fixed will solve Reactive's mysterious
bugs and unblock its progress.
Ok, we can fix the fairly simple bug that a thread created in blocked mode
blocks throwTos after the
Isaac Dupree wrote:
Bertram Felgenhauer wrote:
Now in fact, IO actions are indistinguishable from pure computations by
the RTS, so this mechanism also makes IO actions resumable, in
principle, if you can access the corresponding thunk somehow. Normally
you can't - there is no reference to that
Isaac Dupree wrote:
therefore mapException is equally buggy!
mapException :: (Exception e1, Exception e2) = (e1 - e2) - a - a
mapException f v = unsafePerformIO (catch (evaluate v)
(\x - throw (f x)))
If it maps an asynchronous exception.. and it's
I don't know if the bug would explain loop. My guess is that the
black-hole-detection code is incorrectly concluding there is a black hole
because a thunk was marked as in the process of being evaluated, then the
evaluating thread is killed without unmarking the thunk, and then another
thread
On Mon, Dec 29, 2008 at 05:07:22PM +0100, Bertram Felgenhauer wrote:
Simon Peyton-Jones wrote:
This is odd (to me). The permanently bound stuff applies only to
*synchronous* exceptions, which thread-killing is not. Simon M will
have more to say when he gets back
This is true when
therefore mapException is equally buggy!
mapException :: (Exception e1, Exception e2) = (e1 - e2) - a - a
mapException f v = unsafePerformIO (catch (evaluate v)
(\x - throw (f x)))
If it maps an asynchronous exception.. and it's re-thrown as
Conal Elliott wrote:
Thanks very much for these ideas. Peter Verswyvelen suggested running the
example repeatedly to see if it always runs correctly. He found, and I
verified, that the example runs fine with Bertram's last version of unamb
below, *unless* it's compiled with -threaded and run
Indeed -- many thanks to Bertram, Sterling, Peter others for the help! I
think getting this bug fixed will solve Reactive's mysterious bugs and
unblock its progress.
- Conal
On Sat, Jan 3, 2009 at 1:20 PM, Peter Verswyvelen bugf...@gmail.com wrote:
That is very good news! Let's hope it's
: glasgow-haskell-users-boun...@haskell.org
[mailto:glasgow-haskell-users-boun...@haskell.org] On Behalf Of Conal Elliott
Sent: 26 December 2008 06:15
To: glasgow-haskell-users@haskell.org
Subject: black hole detection and concurrency
I'm looking for information about black hole detection with ghc. I'm
| I have a good theory on the latter symptom (the thread killed
| message). Sticking in some traces, as in my appended code, helped me
| to see what's going on. It seems to be exactly what you describe --
| the variable v is permanently bound to the exception it evaluates
| to. Since the right
Simon Peyton-Jones wrote:
| I have a good theory on the latter symptom (the thread killed
| message). Sticking in some traces, as in my appended code, helped me
| to see what's going on. It seems to be exactly what you describe --
| the variable v is permanently bound to the exception it
Bertram Felgenhauer wrote:
Now in fact, IO actions are indistinguishable from pure computations by
the RTS, so this mechanism also makes IO actions resumable, in
principle, if you can access the corresponding thunk somehow. Normally
you can't - there is no reference to that thunk - but
This is a neat trick indeed! I'd appreciate an explanation of killing one's
own thread and then continuing (with a restart in this case). How does the
post-kill resumption occur? That is, how does control pass to the
tail-recursive call after the self-kill?
- Conal
2008/12/28 Peter
Thanks very much for these ideas. Peter Verswyvelen suggested running the
example repeatedly to see if it always runs correctly. He found, and I
verified, that the example runs fine with Bertram's last version of unamb
below, *unless* it's compiled with -threaded and run with +RTS -N2. In the
Peter Verswyvelen wrote:
I fail to understand this part of the code:
case fromException e of
Just ThreadKilled - do
myThreadId = killThread
unblock (race a b)
So the current thread gets killed synchronously, then then the race
Sterling Clover wrote:
I have a good theory on the latter symptom (the thread killed message).
Sticking in some traces, as in my appended code, helped me to see what's
going on. It seems to be exactly what you describe -- the variable v is
permanently bound to the exception it evaluates to.
On Dec 27, 2008, at 9:02 AM, Bertram Felgenhauer wrote:
The key part here is 'myThreadId = killThread' which throws an
asynchronous exception to the thread itself, causing the update
frames to be saved on the heap.
Note that 'myThreadId = killThread' is not equivalent to
'throw ThreadKilled';
Hi,
Bertram Felgenhauer wrote:
[snip]
race :: IO a - IO a - IO a
Two quick notes on that function:
race a b = block $ do
v - newEmptyMVar
let t x = x = putMVar v
Should be
let t x = unblock (x = putMVar v)
Otherwise the computation 'x' not be interruptible unless it
Sterling Clover wrote:
On Dec 27, 2008, at 9:02 AM, Bertram Felgenhauer wrote:
In the above code, there is a small window between catching the
ThreadKilled exception and throwing it again though, where other
exceptions may creep in. The only way I see of fixing that is to use
'block' and
I have a good theory on the latter symptom (the thread killed
message). Sticking in some traces, as in my appended code, helped me
to see what's going on. It seems to be exactly what you describe --
the variable v is permanently bound to the exception it evaluates
to. Since the right hand
Thanks for the probing, Sterl.
I'm afraid I'm stuck here. Without the more effective thread killing (in
unamb), Reactive seems to be drowning in uselessly running threads. With
improved thread killing, I get many of these false black holes, instead of
computed values.
I don't know whether this
I'm looking for information about black hole detection with ghc. I'm
getting loop where I don't think there is an actual black hole. I get
this message sometimes with the unamb package, which is implemented with
unsafePerformIO, concurrency, and killThread, as described in
25 matches
Mail list logo
