Quantcast

[GHC] #6126: Fix risk of dead-lock in documentation of Control.Concurrent

classic Classic list List threaded Threaded
4 messages Options
GHC
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

[GHC] #6126: Fix risk of dead-lock in documentation of Control.Concurrent

GHC
#6126: Fix risk of dead-lock in documentation of Control.Concurrent
-------------------------------+--------------------------------------------
 Reporter:  basvandijk         |          Owner:                  
     Type:  bug                |         Status:  new            
 Priority:  normal             |      Component:  libraries/base  
  Version:  7.4.1              |       Keywords:                  
       Os:  Unknown/Multiple   |   Architecture:  Unknown/Multiple
  Failure:  Documentation bug  |       Testcase:                  
Blockedby:                     |       Blocking:                  
  Related:                     |  
-------------------------------+--------------------------------------------
 The [http://hackage.haskell.org/packages/archive/base/4.5.0.0/doc/html
 /Control-Concurrent.html#g:12 current] documentation of
 `Control.Concurrent` proposes a function to wait for a child thread to
 complete:

 {{{
    myForkIO :: IO () -> IO (MVar ())
    myForkIO io = do
      mvar <- newEmptyMVar
      forkIO (io `finally` putMVar mvar ())
      return mvar
 }}}

 This function has the risk of causing a dead-lock. If an asynchronous
 exception if thrown before the `putMVar` exception handler is installed
 the `mvar` will remain empty. This causes a dead-lock when the `mvar` is
 taken.

 The attached patch fixes this problem by correctly masking asynchronous
 exceptions before forking. Also, instead of returning the `mvar` it
 returns a computation that waits for the child thread to complete. This is
 safer than returning the `mvar` itself since a user can't accidentally put
 the `mvar` (which will dead-lock) or take the `mvar` (which when executed
 twice will dead-lock).

 The attached patch additionally rewrites the function to wait for a group
 of threads to complete. Instead of keeping a list of `MVars`, I use a
 counter (stored in a `TVar`) that counts the number of running threads.
 The counter is incremented when a thread if forked and decremented when it
 completes. Waiting for the group of threads to complete is accomplished by
 checking if the counter has reached 0 and if not retry the transaction.

--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6126>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler

_______________________________________________
Glasgow-haskell-bugs mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
GHC
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: [GHC] #6126: Fix risk of dead-lock in documentation of Control.Concurrent

GHC
#6126: Fix risk of dead-lock in documentation of Control.Concurrent
---------------------------------+------------------------------------------
    Reporter:  basvandijk        |       Owner:                  
        Type:  bug               |      Status:  new              
    Priority:  normal            |   Milestone:                  
   Component:  libraries/base    |     Version:  7.4.1            
    Keywords:                    |          Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  |     Failure:  Documentation bug
  Difficulty:  Unknown           |    Testcase:                  
   Blockedby:                    |    Blocking:                  
     Related:                    |  
---------------------------------+------------------------------------------
Changes (by simonmar):

  * difficulty:  => Unknown


Comment:

 I've actually been intending to fix this a different way.  I want to add
 `forkFinally`:

 {{{
 forkFinally :: IO a -> (Either SomeException a -> IO ()) -> IO ThreadId
 forkFinally action action =
   mask $ \restore ->
     forkIO $ try (restore action) >>= action
 }}}

 Furthermore I'd like to add an Async API that builds on this to add some
 higher level concurrency operators, but I'll post a proposal on the
 libraries list about this.

--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6126#comment:1>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler

_______________________________________________
Glasgow-haskell-bugs mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
GHC
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: [GHC] #6126: Fix risk of dead-lock in documentation of Control.Concurrent

GHC
In reply to this post by GHC
#6126: Fix risk of dead-lock in documentation of Control.Concurrent
---------------------------------+------------------------------------------
    Reporter:  basvandijk        |       Owner:                  
        Type:  bug               |      Status:  new              
    Priority:  normal            |   Milestone:                  
   Component:  libraries/base    |     Version:  7.4.1            
    Keywords:                    |          Os:  Unknown/Multiple
Architecture:  Unknown/Multiple  |     Failure:  Documentation bug
  Difficulty:  Unknown           |    Testcase:                  
   Blockedby:                    |    Blocking:                  
     Related:                    |  
---------------------------------+------------------------------------------

Comment(by basvandijk):

 I'm looking forward to it. The functions in my
 [http://hackage.haskell.org/packages/archive/threads/0.5/doc/html/Control-
 Concurrent-Thread.html threads] package can also benefit from this. Or
 maybe the package will be deprecated in favor of your new Async API.

--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6126#comment:2>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler

_______________________________________________
Glasgow-haskell-bugs mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
GHC
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate
star

Re: [GHC] #6126: Fix risk of dead-lock in documentation of Control.Concurrent

GHC
In reply to this post by GHC
#6126: Fix risk of dead-lock in documentation of Control.Concurrent
--------------------------------+-------------------------------------------
  Reporter:  basvandijk         |          Owner:                  
      Type:  bug                |         Status:  closed          
  Priority:  normal             |      Milestone:                  
 Component:  libraries/base     |        Version:  7.4.1          
Resolution:  fixed              |       Keywords:                  
        Os:  Unknown/Multiple   |   Architecture:  Unknown/Multiple
   Failure:  Documentation bug  |     Difficulty:  Unknown        
  Testcase:                     |      Blockedby:                  
  Blocking:                     |        Related:                  
--------------------------------+-------------------------------------------
Changes (by simonmar):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 Fixed:

 {{{
 commit 40d1be115d2a5a409e9b747c347cd909a9607c42
 Author: Simon Marlow <[hidden email]>
 Date:   Thu Jun 7 16:10:47 2012 +0100

     add forkFinally

     This is a more robust version of "forkIO (m `finally` k)", because it
     closes a window between thread creation and the finally where the
     thread can receive an async exception.  Useful for layers over threads
     that need to catch threads dying with absolute certainty.

     forkFinally :: IO a -> (Either SomeException a -> IO ()) -> IO
 ThreadId
     forkFinally action and_then =
       mask $ \restore ->
         forkIO $ try (restore action) >>= and_then
 }}}

 and the new `Async` API is currently being discussed on the libraries
 list; a preliminary implementation is here:
 [https://github.com/simonmar/async]

--
Ticket URL: <http://hackage.haskell.org/trac/ghc/ticket/6126#comment:3>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler

_______________________________________________
Glasgow-haskell-bugs mailing list
[hidden email]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Loading...