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
|
|
|
-
|
2021-06-04 20:08:42 +00:00
|
|
|
- Copyright 2010-2021 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
|
2021-02-03 19:21:43 +00:00
|
|
|
import Annex.WorkerPool
|
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
|
2021-06-04 20:08:42 +00:00
|
|
|
import Annex.Content
|
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
|
2021-06-04 20:08:42 +00:00
|
|
|
import Types.ActionItem
|
2021-02-03 19:35:32 +00:00
|
|
|
import Remote.List
|
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
|
2021-06-04 20:43:47 +00:00
|
|
|
- the seek stage. Finishes by running the continuation.
|
|
|
|
-
|
|
|
|
- Can exit when there was a problem or when files were skipped.
|
|
|
|
- Also shows a count of any failures when that is enabled.
|
|
|
|
-}
|
|
|
|
performCommandAction :: Bool -> Command -> CommandSeek -> Annex () -> Annex ()
|
|
|
|
performCommandAction canexit (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
|
2021-06-04 20:43:47 +00:00
|
|
|
st <- Annex.getState id
|
|
|
|
when canexit $ liftIO $ case (Annex.errcounter st, Annex.skippedfiles st) of
|
|
|
|
(0, False) -> noop
|
|
|
|
(errcnt, False) -> do
|
|
|
|
showerrcount errcnt
|
|
|
|
exitWith $ ExitFailure 1
|
|
|
|
(0, True) -> exitskipped
|
|
|
|
(errcnt, True) -> do
|
|
|
|
showerrcount errcnt
|
|
|
|
exitskipped
|
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
|
|
|
where
|
2021-06-04 20:43:47 +00:00
|
|
|
showerrcount cnt = hPutStrLn stderr $
|
|
|
|
name ++ ": " ++ show cnt ++ " failed"
|
|
|
|
exitskipped = exitWith $ ExitFailure 101
|
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 ()
|
2021-06-04 18:56:31 +00:00
|
|
|
commandAction start = do
|
|
|
|
st <- Annex.getState id
|
|
|
|
case getConcurrency' (Annex.concurrency st) of
|
2021-06-04 20:08:42 +00:00
|
|
|
NonConcurrent -> runnonconcurrent (Annex.sizelimit st)
|
2021-06-04 18:56:31 +00:00
|
|
|
Concurrent n
|
2021-06-04 20:08:42 +00:00
|
|
|
| n > 1 -> runconcurrent (Annex.sizelimit st) (Annex.workers st)
|
|
|
|
| otherwise -> runnonconcurrent (Annex.sizelimit st)
|
|
|
|
ConcurrentPerCpu -> runconcurrent (Annex.sizelimit st) (Annex.workers st)
|
2015-04-10 21:08:07 +00:00
|
|
|
where
|
2021-06-04 20:08:42 +00:00
|
|
|
runnonconcurrent sizelimit = start >>= \case
|
|
|
|
Nothing -> noop
|
|
|
|
Just (startmsg, perform) ->
|
|
|
|
checkSizeLimit sizelimit startmsg $ do
|
|
|
|
showStartMessage startmsg
|
|
|
|
void $ accountCommandAction startmsg $
|
|
|
|
performCommandAction' startmsg perform
|
|
|
|
|
|
|
|
runconcurrent sizelimit Nothing = runnonconcurrent sizelimit
|
|
|
|
runconcurrent sizelimit (Just tv) =
|
|
|
|
liftIO (atomically (waitStartWorkerSlot tv)) >>= maybe
|
|
|
|
(runnonconcurrent sizelimit)
|
|
|
|
(runconcurrent' sizelimit tv)
|
|
|
|
runconcurrent' sizelimit tv (workerstrd, workerstage) = do
|
2021-04-02 19:26:21 +00:00
|
|
|
aid <- liftIO $ async $ snd
|
|
|
|
<$> Annex.run workerstrd
|
2021-06-04 20:08:42 +00:00
|
|
|
(concurrentjob sizelimit (fst workerstrd))
|
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
|
|
|
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
|
2021-04-02 19:26:21 +00:00
|
|
|
-- original workerstrd.
|
|
|
|
workerstrd' <- either (const workerstrd) id
|
2019-06-05 23:43:32 +00:00
|
|
|
<$> waitCatch aid
|
|
|
|
atomically $ do
|
|
|
|
pool <- takeTMVar tv
|
2021-04-02 19:26:21 +00:00
|
|
|
let !pool' = deactivateWorker pool aid workerstrd'
|
2019-06-05 23:43:32 +00:00
|
|
|
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
|
|
|
|
2021-06-04 20:08:42 +00:00
|
|
|
concurrentjob sizelimit workerst = start >>= \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
|
|
|
Nothing -> noop
|
|
|
|
Just (startmsg, perform) ->
|
2021-06-04 20:08:42 +00:00
|
|
|
checkSizeLimit sizelimit startmsg $
|
|
|
|
concurrentjob' 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
|
|
|
|
|
|
|
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
|
2021-06-04 20:08:42 +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 }
|
2021-04-02 19:26:21 +00:00
|
|
|
vs <- liftIO $ atomically $ do
|
2019-06-19 22:34:26 +00:00
|
|
|
pool <- readTMVar tv
|
|
|
|
if allIdle pool
|
|
|
|
then return (spareVals pool)
|
|
|
|
else retry
|
2021-04-02 19:26:21 +00:00
|
|
|
mapM_ (mergeState . fst) vs
|
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
|
2020-09-16 14:53:16 +00:00
|
|
|
callCommandAction start = start >>= \case
|
|
|
|
Just (startmsg, perform) -> do
|
|
|
|
showStartMessage startmsg
|
|
|
|
performCommandAction' startmsg perform
|
|
|
|
Nothing -> return True
|
2019-06-12 17:33:15 +00:00
|
|
|
|
|
|
|
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
|
2020-09-16 15:41:28 +00:00
|
|
|
fromcmdline <- getConcurrency
|
2018-10-04 16:47:27 +00:00
|
|
|
fromgitcfg <- annexJobs <$> Annex.getGitConfig
|
2020-09-16 15:41:28 +00:00
|
|
|
let usegitcfg = setConcurrency (ConcurrencyGitConfig 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 }
|
2021-02-03 19:35:32 +00:00
|
|
|
prepDupState
|
2019-06-19 16:35:08 +00:00
|
|
|
st <- dupState
|
2021-04-02 19:26:21 +00:00
|
|
|
rd <- Annex.getRead id
|
2019-06-19 20:12:39 +00:00
|
|
|
liftIO $ atomically $ putTMVar tv $
|
2021-04-02 19:26:21 +00:00
|
|
|
allocateWorkerPool (st, rd) (max n 1) usedstages
|
2019-05-10 17:24:31 +00:00
|
|
|
|
2021-02-03 19:35:32 +00:00
|
|
|
-- Make sure that some expensive actions have been done before
|
|
|
|
-- starting threads. This way the state has them already run,
|
|
|
|
-- and each thread won't try to do them.
|
|
|
|
prepDupState :: Annex ()
|
|
|
|
prepDupState = do
|
|
|
|
_ <- remoteList
|
|
|
|
return ()
|
|
|
|
|
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 $
|
2020-09-16 15:41:28 +00:00
|
|
|
go =<< getConcurrency
|
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
|
2021-04-02 19:26:21 +00:00
|
|
|
tv <- Annex.getRead Annex.activekeys
|
2017-10-17 21:54:38 +00:00
|
|
|
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
|
2021-06-04 20:08:42 +00:00
|
|
|
|
|
|
|
checkSizeLimit :: Maybe (TVar Integer) -> StartMessage -> Annex () -> Annex ()
|
|
|
|
checkSizeLimit Nothing _ a = a
|
|
|
|
checkSizeLimit (Just sizelimitvar) startmsg a =
|
|
|
|
case actionItemKey (mkActionItem startmsg) of
|
|
|
|
Just k -> case fromKey keySize k of
|
|
|
|
Just sz -> go sz
|
|
|
|
Nothing -> do
|
|
|
|
fsz <- catchMaybeIO $ withObjectLoc k $
|
|
|
|
liftIO . getFileSize
|
2021-06-04 20:43:47 +00:00
|
|
|
maybe skipped go fsz
|
2021-06-04 20:08:42 +00:00
|
|
|
Nothing -> a
|
|
|
|
where
|
|
|
|
go sz = do
|
|
|
|
fits <- liftIO $ atomically $ do
|
|
|
|
n <- readTVar sizelimitvar
|
|
|
|
let !n' = n - sz
|
|
|
|
if n' >= 0
|
|
|
|
then do
|
|
|
|
writeTVar sizelimitvar n'
|
|
|
|
return True
|
|
|
|
else return False
|
2021-06-04 20:43:47 +00:00
|
|
|
if fits
|
|
|
|
then a
|
|
|
|
else skipped
|
|
|
|
|
|
|
|
skipped = Annex.changeState $ \s -> s { Annex.skippedfiles = True }
|