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
|
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
|
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-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
|
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 ()
|
2020-09-16 15:41:28 +00:00
|
|
|
commandAction start = getConcurrency >>= \case
|
2019-06-19 16:35:08 +00:00
|
|
|
NonConcurrent -> runnonconcurrent
|
avoid interleaving command stages with Concurrency 1
Before, -J1 was different than no -J: It makes concurrent-output be used
for display, and it actually can run concurrent jobs in some situations.
Eg, a perform stage and a cleanup stage can both run.
dupState is used in several places, and changes NonConcurrent to
Concurrent 1. My concern is that this might, in some case, enable
that concurrent behavior. And in particular, that it might get enabled in
--batch mode, when the user is not expecting concurrent output because
they did not pass -J.
While I don't have a test case where that happens and causes out of
order output, it looks like it could, and so prudent to make this change.
2020-09-16 16:10:45 +00:00
|
|
|
Concurrent n
|
|
|
|
| n > 1 -> runconcurrent
|
|
|
|
| otherwise -> runnonconcurrent
|
2019-06-19 16:35:08 +00:00
|
|
|
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
|
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
|
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
|
|
|
|
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
|
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
|