[Haskell-cafe] Is withAsync absolutely safe?
Can withAsync guarantee that its child will be terminated if the thread executing withAsync gets an exception? To remind, here's an implementation of withAsync: withAsyncUsing :: (IO () - IO ThreadId) - IO a - (Async a - IO b) - IO b -- The bracket version works, but is slow. We can do better by -- hand-coding it: withAsyncUsing doFork = \action inner - do var - newEmptyTMVarIO mask $ \restore - do t - doFork $ try (restore action) = atomically . putTMVar var let a = Async t (readTMVar var) r - restore (inner a) `catchAll` \e - do cancel a; throwIO e cancel a return r I am interested in the case when an exception arrives which transfers control to 'cancel', and then another exception arrives to the same thread. Even though 'catchAll' (which is a type-restricted synonym for catch) masks the exception handler, 'throwTo' inside 'cancel' is interruptible (as stated by the documentation). Will this scenario lead to a thread leakage? Roman ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Is withAsync absolutely safe?
Roman Cheplyaka wrote: Can withAsync guarantee that its child will be terminated if the thread executing withAsync gets an exception? To remind, here's an implementation of withAsync: withAsyncUsing :: (IO () - IO ThreadId) - IO a - (Async a - IO b) - IO b -- The bracket version works, but is slow. We can do better by -- hand-coding it: withAsyncUsing doFork = \action inner - do var - newEmptyTMVarIO mask $ \restore - do t - doFork $ try (restore action) = atomically . putTMVar var let a = Async t (readTMVar var) r - restore (inner a) `catchAll` \e - do cancel a; throwIO e cancel a return r I am interested in the case when an exception arrives which transfers control to 'cancel', and then another exception arrives to the same thread. Even though 'catchAll' (which is a type-restricted synonym for catch) masks the exception handler, 'throwTo' inside 'cancel' is interruptible (as stated by the documentation). Will this scenario lead to a thread leakage? Yes. I guess that 'cancel' should use 'uninterruptibleMask_', but it's a hard call to make (if an async action becomes unresponsive, do we want to risk not being able to deliver any exceptions to the controlling thread just because it wants to terminate the async action?) Best regards, Bertram ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Rank N Kinds
Yes, True :: Bool :: * :: ** :: *** :: :: ... in Haskell is the same as True :: Bool :: Set0 :: Set1 :: Set2 :: Set3 :: ... in Agda And I'm asking for useful examples for *** (Set2 in Agda) and higher cheers Wvv 28 Jul 2013 at 8:44:08, Schonwald [via Haskell] (ml-node+s1045720n5733510...@n5.nabble.com) wrote: hello Wvv, a lot of these ideas have been explored before in related (albeit simpler) languages to haskell, are you familiar with idris, coq, or agda? cheers-Carter On Fri, Jul 26, 2013 at 4:42 PM, Wvv [hidden email] wrote: It was discussed a bit here: http://ghc.haskell.org/trac/ghc/ticket/8090 Rank N Kinds: Main Idea is: If we assume an infinite hierarchy of classifications, we have True :: Bool :: * :: ** :: *** :: :: ... Bool = False, True, ... * = Bool, Sting, Maybe Int, ... ** = *, *-Bool, *-(*-*), ... *** = **, **-*, (**-**)-*, ... ... RankNKinds is also a part of lambda-cube. PlyKinds is just type of ** (Rank2Kinds) class Foo (a :: k) where == class Foo (a :: **) where *** is significant to work with ** data and classes; more general: Rank(N)Kinds is significant to work with Rank(N-1)Kinds First useful use is in Typeable. In GHC 7.8 class Typeable (a::k) where ... == class Typeable (a ::**) where ... But we can't write data Foo (a::k)-(a::k)-* ... deriving Typeable If we redeclare class Typeable (a ::***) where ... or even class Typeable (a ::**) where ... it becomes far enough for many years I'm asking to find other useful examples -- View this message in context: http://haskell.1045720.n5.nabble.com/Rank-N-Kinds-tp5733482.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. ___ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list [hidden email] http://www.haskell.org/mailman/listinfo/haskell-cafe If you reply to this email, your message will be added to the discussion below:http://haskell.1045720.n5.nabble.com/Rank-N-Kinds-tp5733482p5733510.html To unsubscribe from Rank N Kinds, click here. NAML -- View this message in context: http://haskell.1045720.n5.nabble.com/Rank-N-Kinds-tp5733482p5733545.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Munich Haskell Meeting
Dear all, our monthly Haskell Meeting will take place tomorrow, Tuesday the 30th of July, at 19h30 in Munich. Please note that we will meet at Max-Emanuel-Brauerei. If you plan to join, please hit the button at http://www.haskell-munich.de/dates Have a nice week, Heinrich ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
