git-annex/Utility/Parallel.hs

{- parallel processes
 -
 - Copyright 2012 Joey Hess <joey@kitenet.net>
 -
 - Licensed under the GNU GPL version 3 or higher.
 -}

module Utility.Parallel where

import Common

{- Runs an action in parallel with a set of values.
 - Returns the values partitioned into ones with which the action succeeded,
 - and ones with which it failed. -}
inParallel :: (v -> IO ()) -> [v] -> IO ([v], [v])
inParallel a l = do
	pids <- mapM (forkProcess . a) l
	statuses <- mapM (getProcessStatus True False) pids
	return $ reduce $ partition (succeeded . snd) $ zip l statuses
	where
		succeeded v = v == Just (Exited ExitSuccess)
		reduce (x,y) = (map fst x, map fst y)
the syncer now pushes out changes to remotes, in parallel Note that, since this always pushes branch synced/master to the remote, it assumes that master has already gotten all the commits that are on the remote merged in. Otherwise, fast-forward prevention may prevent the push. That's probably ok, because the next stage is to automatically detect incoming pushes and merge. 2012-06-22 19:46:21 +00:00			`{- parallel processes`
			`-`
			`- Copyright 2012 Joey Hess <joey@kitenet.net>`
			`-`
			`- Licensed under the GNU GPL version 3 or higher.`
			`-}`

			`module Utility.Parallel where`

			`import Common`

			`{- Runs an action in parallel with a set of values.`
use a TMVar SampleMVar won't work; between getting the current value and changing it, another thread could made a change, which would get lost. TMVar works well; this update situation is handled by atomic transactions. 2012-06-26 21:33:34 +00:00			`- Returns the values partitioned into ones with which the action succeeded,`
			`- and ones with which it failed. -}`
			`inParallel :: (v -> IO ()) -> [v] -> IO ([v], [v])`
golfing 2012-06-23 05:33:10 +00:00			`inParallel a l = do`
			`pids <- mapM (forkProcess . a) l`
the syncer now pushes out changes to remotes, in parallel Note that, since this always pushes branch synced/master to the remote, it assumes that master has already gotten all the commits that are on the remote merged in. Otherwise, fast-forward prevention may prevent the push. That's probably ok, because the next stage is to automatically detect incoming pushes and merge. 2012-06-22 19:46:21 +00:00			`statuses <- mapM (getProcessStatus True False) pids`
use a TMVar SampleMVar won't work; between getting the current value and changing it, another thread could made a change, which would get lost. TMVar works well; this update situation is handled by atomic transactions. 2012-06-26 21:33:34 +00:00			`return $ reduce $ partition (succeeded . snd) $ zip l statuses`
the syncer now pushes out changes to remotes, in parallel Note that, since this always pushes branch synced/master to the remote, it assumes that master has already gotten all the commits that are on the remote merged in. Otherwise, fast-forward prevention may prevent the push. That's probably ok, because the next stage is to automatically detect incoming pushes and merge. 2012-06-22 19:46:21 +00:00			`where`
use a TMVar SampleMVar won't work; between getting the current value and changing it, another thread could made a change, which would get lost. TMVar works well; this update situation is handled by atomic transactions. 2012-06-26 21:33:34 +00:00			`succeeded v = v == Just (Exited ExitSuccess)`
			`reduce (x,y) = (map fst x, map fst y)`