Nice, thanks, Edward =).
On Tue, Apr 16, 2013 at 6:20 PM, Edward Z. Yang ezy...@mit.edu wrote:
OK, I've updated the docus.
Excerpts from Felipe Almeida Lessa's message of Mon Apr 15 13:34:50 -0700
2013:
Thanks a lot, you're correct! The trouble is, I was misguided by the
Interruptible operations note [1] which states that
The following operations are guaranteed not to be interruptible:
... * everything from Control.Exception ...
Well, it seems that not everything from Control.Exception fits the bill.
Thanks, =)
[1]
http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Exception.html#g:14
On Mon, Apr 15, 2013 at 5:25 PM, Bertram Felgenhauer
bertram.felgenha...@googlemail.com wrote:
Felipe Almeida Lessa wrote:
I have some code that is not behaving the way I thought it should.
The gist of it is
sleeper =
mask_ $
forkIOWithUnmask $ \restore -
forever $
restore sleep `catch` throwBack
throwBack (Ping tid) = myThreadId = throwTo tid . Pong
throwBack (Pong tid) = myThreadId = throwTo tid . Ping
Since (a) throwBack is executed on a masked state, (b) myThreadId is
uninterruptible, and (c) throwTo is uninterruptible, my understanding
is that the sleeper thread should catch all PingPong exceptions and
never let any one of them through.
(c) is wrong, throwTo may block, and blocking operations are interruptible.
http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Exception.html#v:throwTo
explains this in some more detail.
The simplest way that throwTo can actually block in your program, as
far as I can see, and one that will only affect the threaded RTS, is
if the sleeper thread and whichever thread is running the other
throwBack are executing on different capabilities; this will always
cause throwTo to block. (You could try looking at a ghc event log to
find out more.)
I last ran into trouble like that with System.Timeout.timeout; for
that function I finally convinced myself that uninterruptibleMask
is the only way to avoid such problems; then throwTo will not be
interrupted by exceptions even when it blocks. Maybe this is the
solution for your problem, too.
Hope that helps,
Bertram
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
--
Felipe.
___
Glasgow-haskell-users mailing list
Glasgow-haskell-users@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
