finish CommandStart transition
The hoped for optimisation of CommandStart with -J did not materialize.
In fact, not runnign CommandStart in parallel is slower than -J3.
So, CommandStart are still run in parallel.
(The actual bad performance I've been seeing with -J in my big repo
has to do with building the remoteList.)
But, this is still progress toward making -J faster, because it gets rid
of the onlyActionOn roadblock in the way of making CommandCleanup jobs
run separate from CommandPerform jobs.
Added OnlyActionOn constructor for ActionItem which fixes the
onlyActionOn breakage in the last commit.
Made CustomOutput include an ActionItem, so even things using it can
specify OnlyActionOn.
In Command.Move and Command.Sync, there were CommandStarts that used
includeCommandAction, so output messages, which is no longer allowed.
Fixed by using startingCustomOutput, but that's still not quite right,
since it prevents message display for the includeCommandAction run
inside it too.
2019-06-12 13:23:26 +00:00
|
|
|
{- git-annex command-line actions and concurrency
|
fix inversion of control in CommandSeek (no behavior changes)
I've been disliking how the command seek actions were written for some
time, with their inversion of control and ugly workarounds.
The last straw to fix it was sync --content, which didn't fit the
Annex [CommandStart] interface well at all. I have not yet made it take
advantage of the changed interface though.
The crucial change, and probably why I didn't do it this way from the
beginning, is to make each CommandStart action be run with exceptions
caught, and if it fails, increment a failure counter in annex state.
So I finally remove the very first code I wrote for git-annex, which
was before I had exception handling in the Annex monad, and so ran outside
that monad, passing state explicitly as it ran each CommandStart action.
This was a real slog from 1 to 5 am.
Test suite passes.
Memory usage is lower than before, sometimes by a couple of megabytes, and
remains constant, even when running in a large repo, and even when
repeatedly failing and incrementing the error counter. So no accidental
laziness space leaks.
Wall clock speed is identical, even in large repos.
This commit was sponsored by an anonymous bitcoiner.
2014-01-20 08:11:42 +00:00
|
|
|
-
|
2020-05-26 17:44:43 +00:00
|
|
|
- Copyright 2010-2020 Joey Hess <id@joeyh.name>
|
fix inversion of control in CommandSeek (no behavior changes)
I've been disliking how the command seek actions were written for some
time, with their inversion of control and ugly workarounds.
The last straw to fix it was sync --content, which didn't fit the
Annex [CommandStart] interface well at all. I have not yet made it take
advantage of the changed interface though.
The crucial change, and probably why I didn't do it this way from the
beginning, is to make each CommandStart action be run with exceptions
caught, and if it fails, increment a failure counter in annex state.
So I finally remove the very first code I wrote for git-annex, which
was before I had exception handling in the Annex monad, and so ran outside
that monad, passing state explicitly as it ran each CommandStart action.
This was a real slog from 1 to 5 am.
Test suite passes.
Memory usage is lower than before, sometimes by a couple of megabytes, and
remains constant, even when running in a large repo, and even when
repeatedly failing and incrementing the error counter. So no accidental
laziness space leaks.
Wall clock speed is identical, even in large repos.
This commit was sponsored by an anonymous bitcoiner.
2014-01-20 08:11:42 +00:00
|
|
|
-
|
2019-03-13 19:48:14 +00:00
|
|
|
- Licensed under the GNU AGPL version 3 or higher.
|
fix inversion of control in CommandSeek (no behavior changes)
I've been disliking how the command seek actions were written for some
time, with their inversion of control and ugly workarounds.
The last straw to fix it was sync --content, which didn't fit the
Annex [CommandStart] interface well at all. I have not yet made it take
advantage of the changed interface though.
The crucial change, and probably why I didn't do it this way from the
beginning, is to make each CommandStart action be run with exceptions
caught, and if it fails, increment a failure counter in annex state.
So I finally remove the very first code I wrote for git-annex, which
was before I had exception handling in the Annex monad, and so ran outside
that monad, passing state explicitly as it ran each CommandStart action.
This was a real slog from 1 to 5 am.
Test suite passes.
Memory usage is lower than before, sometimes by a couple of megabytes, and
remains constant, even when running in a large repo, and even when
repeatedly failing and incrementing the error counter. So no accidental
laziness space leaks.
Wall clock speed is identical, even in large repos.
This commit was sponsored by an anonymous bitcoiner.
2014-01-20 08:11:42 +00:00
|
|
|
-}
|
|
|
|
|
2019-06-05 23:43:32 +00:00
|
|
|
{-# LANGUAGE CPP, BangPatterns #-}
|
2015-11-05 21:22:45 +00:00
|
|
|
|
2014-01-29 17:44:53 +00:00
|
|
|
module CmdLine.Action where
|
fix inversion of control in CommandSeek (no behavior changes)
I've been disliking how the command seek actions were written for some
time, with their inversion of control and ugly workarounds.
The last straw to fix it was sync --content, which didn't fit the
Annex [CommandStart] interface well at all. I have not yet made it take
advantage of the changed interface though.
The crucial change, and probably why I didn't do it this way from the
beginning, is to make each CommandStart action be run with exceptions
caught, and if it fails, increment a failure counter in annex state.
So I finally remove the very first code I wrote for git-annex, which
was before I had exception handling in the Annex monad, and so ran outside
that monad, passing state explicitly as it ran each CommandStart action.
This was a real slog from 1 to 5 am.
Test suite passes.
Memory usage is lower than before, sometimes by a couple of megabytes, and
remains constant, even when running in a large repo, and even when
repeatedly failing and incrementing the error counter. So no accidental
laziness space leaks.
Wall clock speed is identical, even in large repos.
This commit was sponsored by an anonymous bitcoiner.
2014-01-20 08:11:42 +00:00
|
|
|
|
2016-01-20 20:36:33 +00:00
|
|
|
import Annex.Common
|
fix inversion of control in CommandSeek (no behavior changes)
I've been disliking how the command seek actions were written for some
time, with their inversion of control and ugly workarounds.
The last straw to fix it was sync --content, which didn't fit the
Annex [CommandStart] interface well at all. I have not yet made it take
advantage of the changed interface though.
The crucial change, and probably why I didn't do it this way from the
beginning, is to make each CommandStart action be run with exceptions
caught, and if it fails, increment a failure counter in annex state.
So I finally remove the very first code I wrote for git-annex, which
was before I had exception handling in the Annex monad, and so ran outside
that monad, passing state explicitly as it ran each CommandStart action.
This was a real slog from 1 to 5 am.
Test suite passes.
Memory usage is lower than before, sometimes by a couple of megabytes, and
remains constant, even when running in a large repo, and even when
repeatedly failing and incrementing the error counter. So no accidental
laziness space leaks.
Wall clock speed is identical, even in large repos.
This commit was sponsored by an anonymous bitcoiner.
2014-01-20 08:11:42 +00:00
|
|
|
import qualified Annex
|
2015-04-10 21:53:58 +00:00
|
|
|
import Annex.Concurrent
|
fix inversion of control in CommandSeek (no behavior changes)
I've been disliking how the command seek actions were written for some
time, with their inversion of control and ugly workarounds.
The last straw to fix it was sync --content, which didn't fit the
Annex [CommandStart] interface well at all. I have not yet made it take
advantage of the changed interface though.
The crucial change, and probably why I didn't do it this way from the
beginning, is to make each CommandStart action be run with exceptions
caught, and if it fails, increment a failure counter in annex state.
So I finally remove the very first code I wrote for git-annex, which
was before I had exception handling in the Annex monad, and so ran outside
that monad, passing state explicitly as it ran each CommandStart action.
This was a real slog from 1 to 5 am.
Test suite passes.
Memory usage is lower than before, sometimes by a couple of megabytes, and
remains constant, even when running in a large repo, and even when
repeatedly failing and incrementing the error counter. So no accidental
laziness space leaks.
Wall clock speed is identical, even in large repos.
This commit was sponsored by an anonymous bitcoiner.
2014-01-20 08:11:42 +00:00
|
|
|
import Types.Command
|
2016-09-09 16:57:42 +00:00
|
|
|
import Types.Concurrency
|
2015-11-05 21:22:45 +00:00
|
|
|
import Messages.Concurrent
|
2015-04-10 21:08:07 +00:00
|
|
|
import Types.Messages
|
2019-06-05 17:03:05 +00:00
|
|
|
import Types.WorkerPool
|
2015-04-10 21:08:07 +00:00
|
|
|
|
2017-10-17 21:54:38 +00:00
|
|
|
import Control.Concurrent
|
2015-04-10 21:08:07 +00:00
|
|
|
import Control.Concurrent.Async
|
2017-10-17 21:54:38 +00:00
|
|
|
import Control.Concurrent.STM
|
2019-05-10 17:24:31 +00:00
|
|
|
import GHC.Conc
|
2017-10-17 21:54:38 +00:00
|
|
|
import qualified Data.Map.Strict as M
|
2015-11-05 21:22:45 +00:00
|
|
|
import qualified System.Console.Regions as Regions
|
|
|
|
|
fix inversion of control in CommandSeek (no behavior changes)
I've been disliking how the command seek actions were written for some
time, with their inversion of control and ugly workarounds.
The last straw to fix it was sync --content, which didn't fit the
Annex [CommandStart] interface well at all. I have not yet made it take
advantage of the changed interface though.
The crucial change, and probably why I didn't do it this way from the
beginning, is to make each CommandStart action be run with exceptions
caught, and if it fails, increment a failure counter in annex state.
So I finally remove the very first code I wrote for git-annex, which
was before I had exception handling in the Annex monad, and so ran outside
that monad, passing state explicitly as it ran each CommandStart action.
This was a real slog from 1 to 5 am.
Test suite passes.
Memory usage is lower than before, sometimes by a couple of megabytes, and
remains constant, even when running in a large repo, and even when
repeatedly failing and incrementing the error counter. So no accidental
laziness space leaks.
Wall clock speed is identical, even in large repos.
This commit was sponsored by an anonymous bitcoiner.
2014-01-20 08:11:42 +00:00
|
|
|
{- Runs a command, starting with the check stage, and then
|
2014-12-30 16:49:34 +00:00
|
|
|
- the seek stage. Finishes by running the continutation, and
|
|
|
|
- then showing a count of any failures. -}
|
2015-07-08 16:33:27 +00:00
|
|
|
performCommandAction :: Command -> CommandSeek -> Annex () -> Annex ()
|
|
|
|
performCommandAction Command { cmdcheck = c, cmdname = name } seek cont = do
|
fix inversion of control in CommandSeek (no behavior changes)
I've been disliking how the command seek actions were written for some
time, with their inversion of control and ugly workarounds.
The last straw to fix it was sync --content, which didn't fit the
Annex [CommandStart] interface well at all. I have not yet made it take
advantage of the changed interface though.
The crucial change, and probably why I didn't do it this way from the
beginning, is to make each CommandStart action be run with exceptions
caught, and if it fails, increment a failure counter in annex state.
So I finally remove the very first code I wrote for git-annex, which
was before I had exception handling in the Annex monad, and so ran outside
that monad, passing state explicitly as it ran each CommandStart action.
This was a real slog from 1 to 5 am.
Test suite passes.
Memory usage is lower than before, sometimes by a couple of megabytes, and
remains constant, even when running in a large repo, and even when
repeatedly failing and incrementing the error counter. So no accidental
laziness space leaks.
Wall clock speed is identical, even in large repos.
This commit was sponsored by an anonymous bitcoiner.
2014-01-20 08:11:42 +00:00
|
|
|
mapM_ runCheck c
|
|
|
|
Annex.changeState $ \s -> s { Annex.errcounter = 0 }
|
2015-07-08 16:33:27 +00:00
|
|
|
seek
|
2015-04-10 21:08:07 +00:00
|
|
|
finishCommandActions
|
2014-12-30 16:49:34 +00:00
|
|
|
cont
|
fix inversion of control in CommandSeek (no behavior changes)
I've been disliking how the command seek actions were written for some
time, with their inversion of control and ugly workarounds.
The last straw to fix it was sync --content, which didn't fit the
Annex [CommandStart] interface well at all. I have not yet made it take
advantage of the changed interface though.
The crucial change, and probably why I didn't do it this way from the
beginning, is to make each CommandStart action be run with exceptions
caught, and if it fails, increment a failure counter in annex state.
So I finally remove the very first code I wrote for git-annex, which
was before I had exception handling in the Annex monad, and so ran outside
that monad, passing state explicitly as it ran each CommandStart action.
This was a real slog from 1 to 5 am.
Test suite passes.
Memory usage is lower than before, sometimes by a couple of megabytes, and
remains constant, even when running in a large repo, and even when
repeatedly failing and incrementing the error counter. So no accidental
laziness space leaks.
Wall clock speed is identical, even in large repos.
This commit was sponsored by an anonymous bitcoiner.
2014-01-20 08:11:42 +00:00
|
|
|
showerrcount =<< Annex.getState Annex.errcounter
|
|
|
|
where
|
|
|
|
showerrcount 0 = noop
|
2016-11-16 01:29:54 +00:00
|
|
|
showerrcount cnt = giveup $ name ++ ": " ++ show cnt ++ " failed"
|
fix inversion of control in CommandSeek (no behavior changes)
I've been disliking how the command seek actions were written for some
time, with their inversion of control and ugly workarounds.
The last straw to fix it was sync --content, which didn't fit the
Annex [CommandStart] interface well at all. I have not yet made it take
advantage of the changed interface though.
The crucial change, and probably why I didn't do it this way from the
beginning, is to make each CommandStart action be run with exceptions
caught, and if it fails, increment a failure counter in annex state.
So I finally remove the very first code I wrote for git-annex, which
was before I had exception handling in the Annex monad, and so ran outside
that monad, passing state explicitly as it ran each CommandStart action.
This was a real slog from 1 to 5 am.
Test suite passes.
Memory usage is lower than before, sometimes by a couple of megabytes, and
remains constant, even when running in a large repo, and even when
repeatedly failing and incrementing the error counter. So no accidental
laziness space leaks.
Wall clock speed is identical, even in large repos.
This commit was sponsored by an anonymous bitcoiner.
2014-01-20 08:11:42 +00:00
|
|
|
|
2019-06-05 23:43:32 +00:00
|
|
|
commandActions :: [CommandStart] -> Annex ()
|
|
|
|
commandActions = mapM_ commandAction
|
|
|
|
|
fix inversion of control in CommandSeek (no behavior changes)
I've been disliking how the command seek actions were written for some
time, with their inversion of control and ugly workarounds.
The last straw to fix it was sync --content, which didn't fit the
Annex [CommandStart] interface well at all. I have not yet made it take
advantage of the changed interface though.
The crucial change, and probably why I didn't do it this way from the
beginning, is to make each CommandStart action be run with exceptions
caught, and if it fails, increment a failure counter in annex state.
So I finally remove the very first code I wrote for git-annex, which
was before I had exception handling in the Annex monad, and so ran outside
that monad, passing state explicitly as it ran each CommandStart action.
This was a real slog from 1 to 5 am.
Test suite passes.
Memory usage is lower than before, sometimes by a couple of megabytes, and
remains constant, even when running in a large repo, and even when
repeatedly failing and incrementing the error counter. So no accidental
laziness space leaks.
Wall clock speed is identical, even in large repos.
This commit was sponsored by an anonymous bitcoiner.
2014-01-20 08:11:42 +00:00
|
|
|
{- Runs one of the actions needed to perform a command.
|
|
|
|
- Individual actions can fail without stopping the whole command,
|
2018-11-15 19:59:43 +00:00
|
|
|
- including by throwing non-async exceptions.
|
fix inversion of control in CommandSeek (no behavior changes)
I've been disliking how the command seek actions were written for some
time, with their inversion of control and ugly workarounds.
The last straw to fix it was sync --content, which didn't fit the
Annex [CommandStart] interface well at all. I have not yet made it take
advantage of the changed interface though.
The crucial change, and probably why I didn't do it this way from the
beginning, is to make each CommandStart action be run with exceptions
caught, and if it fails, increment a failure counter in annex state.
So I finally remove the very first code I wrote for git-annex, which
was before I had exception handling in the Annex monad, and so ran outside
that monad, passing state explicitly as it ran each CommandStart action.
This was a real slog from 1 to 5 am.
Test suite passes.
Memory usage is lower than before, sometimes by a couple of megabytes, and
remains constant, even when running in a large repo, and even when
repeatedly failing and incrementing the error counter. So no accidental
laziness space leaks.
Wall clock speed is identical, even in large repos.
This commit was sponsored by an anonymous bitcoiner.
2014-01-20 08:11:42 +00:00
|
|
|
-
|
2015-04-10 21:08:07 +00:00
|
|
|
- When concurrency is enabled, a thread is forked off to run the action
|
2019-06-05 23:43:32 +00:00
|
|
|
- in the background, as soon as a free worker slot is available.
|
2015-04-10 21:08:07 +00:00
|
|
|
|
|
|
|
- This should only be run in the seek stage.
|
|
|
|
-}
|
|
|
|
commandAction :: CommandStart -> Annex ()
|
finish CommandStart transition
The hoped for optimisation of CommandStart with -J did not materialize.
In fact, not runnign CommandStart in parallel is slower than -J3.
So, CommandStart are still run in parallel.
(The actual bad performance I've been seeing with -J in my big repo
has to do with building the remoteList.)
But, this is still progress toward making -J faster, because it gets rid
of the onlyActionOn roadblock in the way of making CommandCleanup jobs
run separate from CommandPerform jobs.
Added OnlyActionOn constructor for ActionItem which fixes the
onlyActionOn breakage in the last commit.
Made CustomOutput include an ActionItem, so even things using it can
specify OnlyActionOn.
In Command.Move and Command.Sync, there were CommandStarts that used
includeCommandAction, so output messages, which is no longer allowed.
Fixed by using startingCustomOutput, but that's still not quite right,
since it prevents message display for the includeCommandAction run
inside it too.
2019-06-12 13:23:26 +00:00
|
|
|
commandAction start = Annex.getState Annex.concurrency >>= \case
|
2019-06-19 16:35:08 +00:00
|
|
|
NonConcurrent -> runnonconcurrent
|
|
|
|
Concurrent _ -> runconcurrent
|
|
|
|
ConcurrentPerCpu -> runconcurrent
|
2015-04-10 21:08:07 +00:00
|
|
|
where
|
2019-06-19 16:35:08 +00:00
|
|
|
runnonconcurrent = void $ includeCommandAction start
|
2019-06-19 19:47:54 +00:00
|
|
|
runconcurrent = Annex.getState Annex.workers >>= \case
|
|
|
|
Nothing -> runnonconcurrent
|
|
|
|
Just tv ->
|
2019-11-14 15:31:43 +00:00
|
|
|
liftIO (atomically (waitStartWorkerSlot tv)) >>=
|
2019-06-19 19:47:54 +00:00
|
|
|
maybe runnonconcurrent (runconcurrent' tv)
|
2019-06-19 16:35:08 +00:00
|
|
|
runconcurrent' tv (workerst, workerstage) = do
|
finish CommandStart transition
The hoped for optimisation of CommandStart with -J did not materialize.
In fact, not runnign CommandStart in parallel is slower than -J3.
So, CommandStart are still run in parallel.
(The actual bad performance I've been seeing with -J in my big repo
has to do with building the remoteList.)
But, this is still progress toward making -J faster, because it gets rid
of the onlyActionOn roadblock in the way of making CommandCleanup jobs
run separate from CommandPerform jobs.
Added OnlyActionOn constructor for ActionItem which fixes the
onlyActionOn breakage in the last commit.
Made CustomOutput include an ActionItem, so even things using it can
specify OnlyActionOn.
In Command.Move and Command.Sync, there were CommandStarts that used
includeCommandAction, so output messages, which is no longer allowed.
Fixed by using startingCustomOutput, but that's still not quite right,
since it prevents message display for the includeCommandAction run
inside it too.
2019-06-12 13:23:26 +00:00
|
|
|
aid <- liftIO $ async $ snd <$> Annex.run workerst
|
|
|
|
(concurrentjob workerst)
|
|
|
|
liftIO $ atomically $ do
|
|
|
|
pool <- takeTMVar tv
|
2019-06-19 16:35:08 +00:00
|
|
|
let !pool' = addWorkerPool (ActiveWorker aid workerstage) pool
|
finish CommandStart transition
The hoped for optimisation of CommandStart with -J did not materialize.
In fact, not runnign CommandStart in parallel is slower than -J3.
So, CommandStart are still run in parallel.
(The actual bad performance I've been seeing with -J in my big repo
has to do with building the remoteList.)
But, this is still progress toward making -J faster, because it gets rid
of the onlyActionOn roadblock in the way of making CommandCleanup jobs
run separate from CommandPerform jobs.
Added OnlyActionOn constructor for ActionItem which fixes the
onlyActionOn breakage in the last commit.
Made CustomOutput include an ActionItem, so even things using it can
specify OnlyActionOn.
In Command.Move and Command.Sync, there were CommandStarts that used
includeCommandAction, so output messages, which is no longer allowed.
Fixed by using startingCustomOutput, but that's still not quite right,
since it prevents message display for the includeCommandAction run
inside it too.
2019-06-12 13:23:26 +00:00
|
|
|
putTMVar tv pool'
|
2019-06-17 18:51:30 +00:00
|
|
|
void $ liftIO $ forkIO $ debugLocks $ do
|
finish CommandStart transition
The hoped for optimisation of CommandStart with -J did not materialize.
In fact, not runnign CommandStart in parallel is slower than -J3.
So, CommandStart are still run in parallel.
(The actual bad performance I've been seeing with -J in my big repo
has to do with building the remoteList.)
But, this is still progress toward making -J faster, because it gets rid
of the onlyActionOn roadblock in the way of making CommandCleanup jobs
run separate from CommandPerform jobs.
Added OnlyActionOn constructor for ActionItem which fixes the
onlyActionOn breakage in the last commit.
Made CustomOutput include an ActionItem, so even things using it can
specify OnlyActionOn.
In Command.Move and Command.Sync, there were CommandStarts that used
includeCommandAction, so output messages, which is no longer allowed.
Fixed by using startingCustomOutput, but that's still not quite right,
since it prevents message display for the includeCommandAction run
inside it too.
2019-06-12 13:23:26 +00:00
|
|
|
-- accountCommandAction will usually catch
|
|
|
|
-- exceptions. Just in case, fall back to the
|
|
|
|
-- original workerst.
|
2019-06-05 23:43:32 +00:00
|
|
|
workerst' <- either (const workerst) id
|
|
|
|
<$> waitCatch aid
|
|
|
|
atomically $ do
|
|
|
|
pool <- takeTMVar tv
|
|
|
|
let !pool' = deactivateWorker pool aid workerst'
|
|
|
|
putTMVar tv pool'
|
finish CommandStart transition
The hoped for optimisation of CommandStart with -J did not materialize.
In fact, not runnign CommandStart in parallel is slower than -J3.
So, CommandStart are still run in parallel.
(The actual bad performance I've been seeing with -J in my big repo
has to do with building the remoteList.)
But, this is still progress toward making -J faster, because it gets rid
of the onlyActionOn roadblock in the way of making CommandCleanup jobs
run separate from CommandPerform jobs.
Added OnlyActionOn constructor for ActionItem which fixes the
onlyActionOn breakage in the last commit.
Made CustomOutput include an ActionItem, so even things using it can
specify OnlyActionOn.
In Command.Move and Command.Sync, there were CommandStarts that used
includeCommandAction, so output messages, which is no longer allowed.
Fixed by using startingCustomOutput, but that's still not quite right,
since it prevents message display for the includeCommandAction run
inside it too.
2019-06-12 13:23:26 +00:00
|
|
|
|
|
|
|
concurrentjob workerst = start >>= \case
|
|
|
|
Nothing -> noop
|
|
|
|
Just (startmsg, perform) ->
|
|
|
|
concurrentjob' workerst startmsg perform
|
|
|
|
|
|
|
|
concurrentjob' workerst startmsg perform = case mkActionItem startmsg of
|
|
|
|
OnlyActionOn k _ -> ensureOnlyActionOn k $
|
|
|
|
-- If another job performed the same action while we
|
|
|
|
-- waited, there may be nothing left to do, so re-run
|
|
|
|
-- the start stage to see if it still wants to do
|
|
|
|
-- something.
|
|
|
|
start >>= \case
|
|
|
|
Just (startmsg', perform') ->
|
|
|
|
case mkActionItem startmsg' of
|
|
|
|
OnlyActionOn k' _ | k' /= k ->
|
|
|
|
concurrentjob' workerst startmsg' perform'
|
2019-11-14 15:31:43 +00:00
|
|
|
_ -> beginjob workerst startmsg' perform'
|
finish CommandStart transition
The hoped for optimisation of CommandStart with -J did not materialize.
In fact, not runnign CommandStart in parallel is slower than -J3.
So, CommandStart are still run in parallel.
(The actual bad performance I've been seeing with -J in my big repo
has to do with building the remoteList.)
But, this is still progress toward making -J faster, because it gets rid
of the onlyActionOn roadblock in the way of making CommandCleanup jobs
run separate from CommandPerform jobs.
Added OnlyActionOn constructor for ActionItem which fixes the
onlyActionOn breakage in the last commit.
Made CustomOutput include an ActionItem, so even things using it can
specify OnlyActionOn.
In Command.Move and Command.Sync, there were CommandStarts that used
includeCommandAction, so output messages, which is no longer allowed.
Fixed by using startingCustomOutput, but that's still not quite right,
since it prevents message display for the includeCommandAction run
inside it too.
2019-06-12 13:23:26 +00:00
|
|
|
Nothing -> noop
|
2019-11-14 15:31:43 +00:00
|
|
|
_ -> beginjob workerst startmsg perform
|
finish CommandStart transition
The hoped for optimisation of CommandStart with -J did not materialize.
In fact, not runnign CommandStart in parallel is slower than -J3.
So, CommandStart are still run in parallel.
(The actual bad performance I've been seeing with -J in my big repo
has to do with building the remoteList.)
But, this is still progress toward making -J faster, because it gets rid
of the onlyActionOn roadblock in the way of making CommandCleanup jobs
run separate from CommandPerform jobs.
Added OnlyActionOn constructor for ActionItem which fixes the
onlyActionOn breakage in the last commit.
Made CustomOutput include an ActionItem, so even things using it can
specify OnlyActionOn.
In Command.Move and Command.Sync, there were CommandStarts that used
includeCommandAction, so output messages, which is no longer allowed.
Fixed by using startingCustomOutput, but that's still not quite right,
since it prevents message display for the includeCommandAction run
inside it too.
2019-06-12 13:23:26 +00:00
|
|
|
|
2019-11-14 15:31:43 +00:00
|
|
|
beginjob workerst startmsg perform =
|
|
|
|
inOwnConsoleRegion (Annex.output workerst) $ do
|
|
|
|
enteringInitialStage
|
2019-06-12 17:33:15 +00:00
|
|
|
void $ accountCommandAction startmsg $
|
finish CommandStart transition
The hoped for optimisation of CommandStart with -J did not materialize.
In fact, not runnign CommandStart in parallel is slower than -J3.
So, CommandStart are still run in parallel.
(The actual bad performance I've been seeing with -J in my big repo
has to do with building the remoteList.)
But, this is still progress toward making -J faster, because it gets rid
of the onlyActionOn roadblock in the way of making CommandCleanup jobs
run separate from CommandPerform jobs.
Added OnlyActionOn constructor for ActionItem which fixes the
onlyActionOn breakage in the last commit.
Made CustomOutput include an ActionItem, so even things using it can
specify OnlyActionOn.
In Command.Move and Command.Sync, there were CommandStarts that used
includeCommandAction, so output messages, which is no longer allowed.
Fixed by using startingCustomOutput, but that's still not quite right,
since it prevents message display for the includeCommandAction run
inside it too.
2019-06-12 13:23:26 +00:00
|
|
|
performconcurrent startmsg perform
|
|
|
|
|
2019-06-12 17:33:15 +00:00
|
|
|
-- Like performCommandAction' but the worker thread's stage
|
|
|
|
-- is changed before starting the cleanup action.
|
finish CommandStart transition
The hoped for optimisation of CommandStart with -J did not materialize.
In fact, not runnign CommandStart in parallel is slower than -J3.
So, CommandStart are still run in parallel.
(The actual bad performance I've been seeing with -J in my big repo
has to do with building the remoteList.)
But, this is still progress toward making -J faster, because it gets rid
of the onlyActionOn roadblock in the way of making CommandCleanup jobs
run separate from CommandPerform jobs.
Added OnlyActionOn constructor for ActionItem which fixes the
onlyActionOn breakage in the last commit.
Made CustomOutput include an ActionItem, so even things using it can
specify OnlyActionOn.
In Command.Move and Command.Sync, there were CommandStarts that used
includeCommandAction, so output messages, which is no longer allowed.
Fixed by using startingCustomOutput, but that's still not quite right,
since it prevents message display for the includeCommandAction run
inside it too.
2019-06-12 13:23:26 +00:00
|
|
|
performconcurrent startmsg perform = do
|
|
|
|
showStartMessage startmsg
|
|
|
|
perform >>= \case
|
2019-06-19 16:35:08 +00:00
|
|
|
Just cleanup -> enteringStage CleanupStage $ do
|
finish CommandStart transition
The hoped for optimisation of CommandStart with -J did not materialize.
In fact, not runnign CommandStart in parallel is slower than -J3.
So, CommandStart are still run in parallel.
(The actual bad performance I've been seeing with -J in my big repo
has to do with building the remoteList.)
But, this is still progress toward making -J faster, because it gets rid
of the onlyActionOn roadblock in the way of making CommandCleanup jobs
run separate from CommandPerform jobs.
Added OnlyActionOn constructor for ActionItem which fixes the
onlyActionOn breakage in the last commit.
Made CustomOutput include an ActionItem, so even things using it can
specify OnlyActionOn.
In Command.Move and Command.Sync, there were CommandStarts that used
includeCommandAction, so output messages, which is no longer allowed.
Fixed by using startingCustomOutput, but that's still not quite right,
since it prevents message display for the includeCommandAction run
inside it too.
2019-06-12 13:23:26 +00:00
|
|
|
r <- cleanup
|
2019-06-12 17:33:15 +00:00
|
|
|
showEndMessage startmsg r
|
finish CommandStart transition
The hoped for optimisation of CommandStart with -J did not materialize.
In fact, not runnign CommandStart in parallel is slower than -J3.
So, CommandStart are still run in parallel.
(The actual bad performance I've been seeing with -J in my big repo
has to do with building the remoteList.)
But, this is still progress toward making -J faster, because it gets rid
of the onlyActionOn roadblock in the way of making CommandCleanup jobs
run separate from CommandPerform jobs.
Added OnlyActionOn constructor for ActionItem which fixes the
onlyActionOn breakage in the last commit.
Made CustomOutput include an ActionItem, so even things using it can
specify OnlyActionOn.
In Command.Move and Command.Sync, there were CommandStarts that used
includeCommandAction, so output messages, which is no longer allowed.
Fixed by using startingCustomOutput, but that's still not quite right,
since it prevents message display for the includeCommandAction run
inside it too.
2019-06-12 13:23:26 +00:00
|
|
|
return r
|
|
|
|
Nothing -> do
|
2019-06-12 17:33:15 +00:00
|
|
|
showEndMessage startmsg False
|
finish CommandStart transition
The hoped for optimisation of CommandStart with -J did not materialize.
In fact, not runnign CommandStart in parallel is slower than -J3.
So, CommandStart are still run in parallel.
(The actual bad performance I've been seeing with -J in my big repo
has to do with building the remoteList.)
But, this is still progress toward making -J faster, because it gets rid
of the onlyActionOn roadblock in the way of making CommandCleanup jobs
run separate from CommandPerform jobs.
Added OnlyActionOn constructor for ActionItem which fixes the
onlyActionOn breakage in the last commit.
Made CustomOutput include an ActionItem, so even things using it can
specify OnlyActionOn.
In Command.Move and Command.Sync, there were CommandStarts that used
includeCommandAction, so output messages, which is no longer allowed.
Fixed by using startingCustomOutput, but that's still not quite right,
since it prevents message display for the includeCommandAction run
inside it too.
2019-06-12 13:23:26 +00:00
|
|
|
return False
|
2015-04-10 21:08:07 +00:00
|
|
|
|
2019-06-05 23:43:32 +00:00
|
|
|
{- Waits for all worker threads to finish and merges their AnnexStates
|
|
|
|
- back into the current Annex's state.
|
2015-04-10 21:08:07 +00:00
|
|
|
-}
|
|
|
|
finishCommandActions :: Annex ()
|
2019-06-19 19:47:54 +00:00
|
|
|
finishCommandActions = Annex.getState Annex.workers >>= \case
|
|
|
|
Nothing -> noop
|
|
|
|
Just tv -> do
|
|
|
|
Annex.changeState $ \s -> s { Annex.workers = Nothing }
|
2019-06-19 22:34:26 +00:00
|
|
|
sts <- liftIO $ atomically $ do
|
|
|
|
pool <- readTMVar tv
|
|
|
|
if allIdle pool
|
|
|
|
then return (spareVals pool)
|
|
|
|
else retry
|
|
|
|
mapM_ mergeState sts
|
2019-06-05 21:54:35 +00:00
|
|
|
|
2020-05-26 17:44:43 +00:00
|
|
|
{- Waits for all worker threads that have been started so far to finish. -}
|
|
|
|
waitForAllRunningCommandActions :: Annex ()
|
|
|
|
waitForAllRunningCommandActions = Annex.getState Annex.workers >>= \case
|
|
|
|
Nothing -> noop
|
|
|
|
Just tv -> liftIO $ atomically $ do
|
|
|
|
pool <- readTMVar tv
|
|
|
|
unless (allIdle pool)
|
|
|
|
retry
|
|
|
|
|
2015-04-10 21:08:07 +00:00
|
|
|
{- Like commandAction, but without the concurrency. -}
|
|
|
|
includeCommandAction :: CommandStart -> CommandCleanup
|
2019-06-12 17:33:15 +00:00
|
|
|
includeCommandAction start =
|
|
|
|
start >>= \case
|
|
|
|
Nothing -> return True
|
|
|
|
Just (startmsg, perform) -> do
|
|
|
|
showStartMessage startmsg
|
|
|
|
accountCommandAction startmsg $
|
|
|
|
performCommandAction' startmsg perform
|
finish CommandStart transition
The hoped for optimisation of CommandStart with -J did not materialize.
In fact, not runnign CommandStart in parallel is slower than -J3.
So, CommandStart are still run in parallel.
(The actual bad performance I've been seeing with -J in my big repo
has to do with building the remoteList.)
But, this is still progress toward making -J faster, because it gets rid
of the onlyActionOn roadblock in the way of making CommandCleanup jobs
run separate from CommandPerform jobs.
Added OnlyActionOn constructor for ActionItem which fixes the
onlyActionOn breakage in the last commit.
Made CustomOutput include an ActionItem, so even things using it can
specify OnlyActionOn.
In Command.Move and Command.Sync, there were CommandStarts that used
includeCommandAction, so output messages, which is no longer allowed.
Fixed by using startingCustomOutput, but that's still not quite right,
since it prevents message display for the includeCommandAction run
inside it too.
2019-06-12 13:23:26 +00:00
|
|
|
|
2019-06-12 17:33:15 +00:00
|
|
|
accountCommandAction :: StartMessage -> CommandCleanup -> CommandCleanup
|
|
|
|
accountCommandAction startmsg cleanup = tryNonAsync cleanup >>= \case
|
finish CommandStart transition
The hoped for optimisation of CommandStart with -J did not materialize.
In fact, not runnign CommandStart in parallel is slower than -J3.
So, CommandStart are still run in parallel.
(The actual bad performance I've been seeing with -J in my big repo
has to do with building the remoteList.)
But, this is still progress toward making -J faster, because it gets rid
of the onlyActionOn roadblock in the way of making CommandCleanup jobs
run separate from CommandPerform jobs.
Added OnlyActionOn constructor for ActionItem which fixes the
onlyActionOn breakage in the last commit.
Made CustomOutput include an ActionItem, so even things using it can
specify OnlyActionOn.
In Command.Move and Command.Sync, there were CommandStarts that used
includeCommandAction, so output messages, which is no longer allowed.
Fixed by using startingCustomOutput, but that's still not quite right,
since it prevents message display for the includeCommandAction run
inside it too.
2019-06-12 13:23:26 +00:00
|
|
|
Right True -> return True
|
|
|
|
Right False -> incerr
|
|
|
|
Left err -> case fromException err of
|
2018-11-19 17:18:08 +00:00
|
|
|
Just exitcode -> liftIO $ exitWith exitcode
|
|
|
|
Nothing -> do
|
|
|
|
toplevelWarning True (show err)
|
2019-06-12 17:33:15 +00:00
|
|
|
showEndMessage startmsg False
|
2018-11-19 17:18:08 +00:00
|
|
|
incerr
|
finish CommandStart transition
The hoped for optimisation of CommandStart with -J did not materialize.
In fact, not runnign CommandStart in parallel is slower than -J3.
So, CommandStart are still run in parallel.
(The actual bad performance I've been seeing with -J in my big repo
has to do with building the remoteList.)
But, this is still progress toward making -J faster, because it gets rid
of the onlyActionOn roadblock in the way of making CommandCleanup jobs
run separate from CommandPerform jobs.
Added OnlyActionOn constructor for ActionItem which fixes the
onlyActionOn breakage in the last commit.
Made CustomOutput include an ActionItem, so even things using it can
specify OnlyActionOn.
In Command.Move and Command.Sync, there were CommandStarts that used
includeCommandAction, so output messages, which is no longer allowed.
Fixed by using startingCustomOutput, but that's still not quite right,
since it prevents message display for the includeCommandAction run
inside it too.
2019-06-12 13:23:26 +00:00
|
|
|
where
|
2014-01-20 17:31:03 +00:00
|
|
|
incerr = do
|
2015-04-30 19:04:01 +00:00
|
|
|
Annex.incError
|
2014-01-20 17:31:03 +00:00
|
|
|
return False
|
fix inversion of control in CommandSeek (no behavior changes)
I've been disliking how the command seek actions were written for some
time, with their inversion of control and ugly workarounds.
The last straw to fix it was sync --content, which didn't fit the
Annex [CommandStart] interface well at all. I have not yet made it take
advantage of the changed interface though.
The crucial change, and probably why I didn't do it this way from the
beginning, is to make each CommandStart action be run with exceptions
caught, and if it fails, increment a failure counter in annex state.
So I finally remove the very first code I wrote for git-annex, which
was before I had exception handling in the Annex monad, and so ran outside
that monad, passing state explicitly as it ran each CommandStart action.
This was a real slog from 1 to 5 am.
Test suite passes.
Memory usage is lower than before, sometimes by a couple of megabytes, and
remains constant, even when running in a large repo, and even when
repeatedly failing and incrementing the error counter. So no accidental
laziness space leaks.
Wall clock speed is identical, even in large repos.
This commit was sponsored by an anonymous bitcoiner.
2014-01-20 08:11:42 +00:00
|
|
|
|
2014-01-20 17:31:03 +00:00
|
|
|
{- Runs a single command action through the start, perform and cleanup
|
finish CommandStart transition
The hoped for optimisation of CommandStart with -J did not materialize.
In fact, not runnign CommandStart in parallel is slower than -J3.
So, CommandStart are still run in parallel.
(The actual bad performance I've been seeing with -J in my big repo
has to do with building the remoteList.)
But, this is still progress toward making -J faster, because it gets rid
of the onlyActionOn roadblock in the way of making CommandCleanup jobs
run separate from CommandPerform jobs.
Added OnlyActionOn constructor for ActionItem which fixes the
onlyActionOn breakage in the last commit.
Made CustomOutput include an ActionItem, so even things using it can
specify OnlyActionOn.
In Command.Move and Command.Sync, there were CommandStarts that used
includeCommandAction, so output messages, which is no longer allowed.
Fixed by using startingCustomOutput, but that's still not quite right,
since it prevents message display for the includeCommandAction run
inside it too.
2019-06-12 13:23:26 +00:00
|
|
|
- stages, without catching errors and without incrementing error counter.
|
|
|
|
- Useful if one command wants to run part of another command. -}
|
2015-04-10 21:08:07 +00:00
|
|
|
callCommandAction :: CommandStart -> CommandCleanup
|
2016-01-19 21:46:46 +00:00
|
|
|
callCommandAction = fromMaybe True <$$> callCommandAction'
|
|
|
|
|
|
|
|
{- Like callCommandAction, but returns Nothing when the command did not
|
|
|
|
- perform any action. -}
|
|
|
|
callCommandAction' :: CommandStart -> Annex (Maybe Bool)
|
2019-06-12 17:33:15 +00:00
|
|
|
callCommandAction' start =
|
make CommandStart return a StartMessage
The goal is to be able to run CommandStart in the main thread when -J is
used, rather than unncessarily passing it off to a worker thread, which
incurs overhead that is signficant when the CommandStart is going to
quickly decide to stop.
To do that, the message it displays needs to be displayed in the worker
thread, after the CommandStart has run.
Also, the change will mean that CommandStart will no longer necessarily
run with the same Annex state as CommandPerform. While its docs already
said it should avoid modifying Annex state, I audited all the
CommandStart code as part of the conversion. (Note that CommandSeek
already sometimes runs with a different Annex state, and that has not been
a source of any problems, so I am not too worried that this change will
lead to breakage going forward.)
The only modification of Annex state I found was it calling
allowMessages in some Commands that default to noMessages. Dealt with
that by adding a startCustomOutput and a startingUsualMessages.
This lets a command start with noMessages and then select the output it
wants for each CommandStart.
One bit of breakage: onlyActionOn has been removed from commands that used it.
The plan is that, since a StartMessage contains an ActionItem,
when a Key can be extracted from that, the parallel job runner can
run onlyActionOn' automatically. Then commands won't need to worry about
this detail. Future work.
Otherwise, this was a fairly straightforward process of making each
CommandStart compile again. Hopefully other behavior changes were mostly
avoided.
In a few cases, a command had a CommandStart that called a CommandPerform
that then called showStart multiple times. I have collapsed those
down to a single start action. The main command to perhaps suffer from it
is Command.Direct, which used to show a start for each file, and no
longer does.
Another minor behavior change is that some commands used showStart
before, but had an associated file and a Key available, so were changed
to ShowStart with an ActionItemAssociatedFile. That will not change the
normal output or behavior, but --json output will now include the key.
This should not break it for anyone using a real json parser.
2019-06-06 19:42:30 +00:00
|
|
|
start >>= \case
|
|
|
|
Nothing -> return Nothing
|
|
|
|
Just (startmsg, perform) -> do
|
|
|
|
showStartMessage startmsg
|
2019-06-12 17:33:15 +00:00
|
|
|
Just <$> performCommandAction' startmsg perform
|
|
|
|
|
|
|
|
performCommandAction' :: StartMessage -> CommandPerform -> CommandCleanup
|
|
|
|
performCommandAction' startmsg perform =
|
|
|
|
perform >>= \case
|
|
|
|
Nothing -> do
|
|
|
|
showEndMessage startmsg False
|
|
|
|
return False
|
|
|
|
Just cleanup -> do
|
|
|
|
r <- cleanup
|
|
|
|
showEndMessage startmsg r
|
|
|
|
return r
|
2015-11-05 21:22:45 +00:00
|
|
|
|
2019-06-19 16:35:08 +00:00
|
|
|
{- Start concurrency when that has been requested.
|
|
|
|
- Should be run wrapping the seek stage of a command.
|
|
|
|
-
|
|
|
|
- Note that a duplicate of the Annex state is made here, and worker
|
|
|
|
- threads use that state. While the worker threads are not actually
|
|
|
|
- started here, that has the same effect.
|
|
|
|
-}
|
|
|
|
startConcurrency :: UsedStages -> Annex a -> Annex a
|
|
|
|
startConcurrency usedstages a = do
|
2018-10-04 16:47:27 +00:00
|
|
|
fromcmdline <- Annex.getState Annex.concurrency
|
|
|
|
fromgitcfg <- annexJobs <$> Annex.getGitConfig
|
2020-04-20 17:53:27 +00:00
|
|
|
let usegitcfg = setConcurrency fromgitcfg
|
2018-10-04 16:47:27 +00:00
|
|
|
case (fromcmdline, fromgitcfg) of
|
|
|
|
(NonConcurrent, NonConcurrent) -> a
|
2019-06-19 16:35:08 +00:00
|
|
|
(Concurrent n, _) ->
|
|
|
|
goconcurrent n
|
|
|
|
(ConcurrentPerCpu, _) ->
|
|
|
|
goconcurrentpercpu
|
2018-10-04 16:47:27 +00:00
|
|
|
(NonConcurrent, Concurrent n) -> do
|
2019-05-10 17:24:31 +00:00
|
|
|
usegitcfg
|
2019-06-19 16:35:08 +00:00
|
|
|
goconcurrent n
|
2019-05-10 17:24:31 +00:00
|
|
|
(NonConcurrent, ConcurrentPerCpu) -> do
|
|
|
|
usegitcfg
|
2019-06-19 16:35:08 +00:00
|
|
|
goconcurrentpercpu
|
2015-11-05 21:22:45 +00:00
|
|
|
where
|
2019-06-19 16:35:08 +00:00
|
|
|
goconcurrent n = do
|
|
|
|
raisecapabilitiesto n
|
2018-11-15 18:26:40 +00:00
|
|
|
withMessageState $ \s -> case outputType s of
|
|
|
|
NormalOutput -> ifM (liftIO concurrentOutputSupported)
|
|
|
|
( Regions.displayConsoleRegions $
|
2019-06-19 20:12:39 +00:00
|
|
|
goconcurrent' n True
|
|
|
|
, goconcurrent' n False
|
2018-11-15 18:26:40 +00:00
|
|
|
)
|
2019-06-19 20:12:39 +00:00
|
|
|
_ -> goconcurrent' n False
|
|
|
|
goconcurrent' n b = bracket_ (setup n b) cleanup a
|
2019-05-10 17:24:31 +00:00
|
|
|
|
2019-06-19 16:35:08 +00:00
|
|
|
goconcurrentpercpu = goconcurrent =<< liftIO getNumProcessors
|
|
|
|
|
2019-06-19 20:12:39 +00:00
|
|
|
setup n b = do
|
|
|
|
setconcurrentoutputenabled b
|
|
|
|
initworkerpool n
|
2019-05-10 17:24:31 +00:00
|
|
|
|
2015-11-05 21:22:45 +00:00
|
|
|
cleanup = do
|
|
|
|
finishCommandActions
|
2018-10-04 16:47:27 +00:00
|
|
|
setconcurrentoutputenabled False
|
2019-05-10 17:24:31 +00:00
|
|
|
|
2018-10-04 16:47:27 +00:00
|
|
|
setconcurrentoutputenabled b = Annex.changeState $ \s ->
|
2016-09-09 16:57:42 +00:00
|
|
|
s { Annex.output = (Annex.output s) { concurrentOutputEnabled = b } }
|
2017-10-17 21:54:38 +00:00
|
|
|
|
2019-05-10 17:24:31 +00:00
|
|
|
raisecapabilitiesto n = do
|
|
|
|
c <- liftIO getNumCapabilities
|
|
|
|
when (n > c) $
|
|
|
|
liftIO $ setNumCapabilities n
|
2019-06-19 16:35:08 +00:00
|
|
|
|
|
|
|
initworkerpool n = do
|
2019-06-19 20:12:39 +00:00
|
|
|
tv <- liftIO newEmptyTMVarIO
|
|
|
|
Annex.changeState $ \s -> s { Annex.workers = Just tv }
|
2019-06-19 16:35:08 +00:00
|
|
|
st <- dupState
|
2019-06-19 20:12:39 +00:00
|
|
|
liftIO $ atomically $ putTMVar tv $
|
2019-06-19 16:35:08 +00:00
|
|
|
allocateWorkerPool st (max n 1) usedstages
|
2019-05-10 17:24:31 +00:00
|
|
|
|
2017-10-17 21:54:38 +00:00
|
|
|
{- Ensures that only one thread processes a key at a time.
|
finish CommandStart transition
The hoped for optimisation of CommandStart with -J did not materialize.
In fact, not runnign CommandStart in parallel is slower than -J3.
So, CommandStart are still run in parallel.
(The actual bad performance I've been seeing with -J in my big repo
has to do with building the remoteList.)
But, this is still progress toward making -J faster, because it gets rid
of the onlyActionOn roadblock in the way of making CommandCleanup jobs
run separate from CommandPerform jobs.
Added OnlyActionOn constructor for ActionItem which fixes the
onlyActionOn breakage in the last commit.
Made CustomOutput include an ActionItem, so even things using it can
specify OnlyActionOn.
In Command.Move and Command.Sync, there were CommandStarts that used
includeCommandAction, so output messages, which is no longer allowed.
Fixed by using startingCustomOutput, but that's still not quite right,
since it prevents message display for the includeCommandAction run
inside it too.
2019-06-12 13:23:26 +00:00
|
|
|
- Other threads will block until it's done.
|
|
|
|
-
|
|
|
|
- May be called repeatedly by the same thread without blocking. -}
|
|
|
|
ensureOnlyActionOn :: Key -> Annex a -> Annex a
|
2019-06-17 18:51:30 +00:00
|
|
|
ensureOnlyActionOn k a = debugLocks $
|
finish CommandStart transition
The hoped for optimisation of CommandStart with -J did not materialize.
In fact, not runnign CommandStart in parallel is slower than -J3.
So, CommandStart are still run in parallel.
(The actual bad performance I've been seeing with -J in my big repo
has to do with building the remoteList.)
But, this is still progress toward making -J faster, because it gets rid
of the onlyActionOn roadblock in the way of making CommandCleanup jobs
run separate from CommandPerform jobs.
Added OnlyActionOn constructor for ActionItem which fixes the
onlyActionOn breakage in the last commit.
Made CustomOutput include an ActionItem, so even things using it can
specify OnlyActionOn.
In Command.Move and Command.Sync, there were CommandStarts that used
includeCommandAction, so output messages, which is no longer allowed.
Fixed by using startingCustomOutput, but that's still not quite right,
since it prevents message display for the includeCommandAction run
inside it too.
2019-06-12 13:23:26 +00:00
|
|
|
go =<< Annex.getState Annex.concurrency
|
2017-10-17 21:54:38 +00:00
|
|
|
where
|
|
|
|
go NonConcurrent = a
|
2019-05-10 17:24:31 +00:00
|
|
|
go (Concurrent _) = goconcurrent
|
|
|
|
go ConcurrentPerCpu = goconcurrent
|
|
|
|
goconcurrent = do
|
2017-10-17 21:54:38 +00:00
|
|
|
tv <- Annex.getState Annex.activekeys
|
|
|
|
bracket (setup tv) id (const a)
|
|
|
|
setup tv = liftIO $ do
|
|
|
|
mytid <- myThreadId
|
|
|
|
atomically $ do
|
|
|
|
m <- readTVar tv
|
|
|
|
case M.lookup k m of
|
|
|
|
Just tid
|
|
|
|
| tid /= mytid -> retry
|
finish CommandStart transition
The hoped for optimisation of CommandStart with -J did not materialize.
In fact, not runnign CommandStart in parallel is slower than -J3.
So, CommandStart are still run in parallel.
(The actual bad performance I've been seeing with -J in my big repo
has to do with building the remoteList.)
But, this is still progress toward making -J faster, because it gets rid
of the onlyActionOn roadblock in the way of making CommandCleanup jobs
run separate from CommandPerform jobs.
Added OnlyActionOn constructor for ActionItem which fixes the
onlyActionOn breakage in the last commit.
Made CustomOutput include an ActionItem, so even things using it can
specify OnlyActionOn.
In Command.Move and Command.Sync, there were CommandStarts that used
includeCommandAction, so output messages, which is no longer allowed.
Fixed by using startingCustomOutput, but that's still not quite right,
since it prevents message display for the includeCommandAction run
inside it too.
2019-06-12 13:23:26 +00:00
|
|
|
| otherwise -> return $ return ()
|
2017-10-17 21:54:38 +00:00
|
|
|
Nothing -> do
|
|
|
|
writeTVar tv $! M.insert k mytid m
|
|
|
|
return $ liftIO $ atomically $
|
|
|
|
modifyTVar tv $ M.delete k
|