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
