2012-10-30 18:34:48 +00:00
|
|
|
{- git-annex assistant named threads.
|
|
|
|
-
|
2015-01-21 16:50:09 +00:00
|
|
|
- Copyright 2012 Joey Hess <id@joeyh.name>
|
2012-10-30 18:34:48 +00:00
|
|
|
-
|
|
|
|
- Licensed under the GNU GPL version 3 or higher.
|
|
|
|
-}
|
|
|
|
|
2013-02-06 19:38:41 +00:00
|
|
|
{-# LANGUAGE CPP #-}
|
|
|
|
|
2012-10-30 18:34:48 +00:00
|
|
|
module Assistant.NamedThread where
|
|
|
|
|
2016-01-20 20:36:33 +00:00
|
|
|
import Annex.Common
|
2013-01-26 06:09:33 +00:00
|
|
|
import Assistant.Types.NamedThread
|
|
|
|
import Assistant.Types.ThreadName
|
2013-01-26 03:14:32 +00:00
|
|
|
import Assistant.Types.DaemonStatus
|
2013-04-03 21:44:34 +00:00
|
|
|
import Assistant.Types.UrlRenderer
|
2012-10-30 18:34:48 +00:00
|
|
|
import Assistant.DaemonStatus
|
2013-01-26 03:14:32 +00:00
|
|
|
import Assistant.Monad
|
assistant: Detect stale git lock files at startup time, and remove them.
Extends the index.lock handling to other git lock files. I surveyed
all lock files used by git, and found more than I expected. All are
handled the same in git; it leaves them open while doing the operation,
possibly writing the new file content to the lock file, and then closes
them when done.
The gc.pid file is excluded because it won't affect the normal operation
of the assistant, and waiting for a gc to finish on startup wouldn't be
good.
All threads except the webapp thread wait on the new startup sanity checker
thread to complete, so they won't try to do things with git that fail
due to stale lock files. The webapp thread mostly avoids doing that kind of
thing itself. A few configurators might fail on lock files, but only if the
user is explicitly trying to run them. The webapp needs to start
immediately when the user has opened it, even if there are stale lock
files.
Arranging for the threads to wait on the startup sanity checker was a bit
of a bear. Have to get all the NotificationHandles set up before the
startup sanity checker runs, or they won't see its signal. Perhaps
the NotificationBroadcaster is not the best interface to have used for
this. Oh well, it works.
This commit was sponsored by Michael Jakl
2013-10-05 21:02:11 +00:00
|
|
|
import Utility.NotificationBroadcaster
|
2012-10-30 18:34:48 +00:00
|
|
|
|
2013-01-26 03:14:32 +00:00
|
|
|
import Control.Concurrent
|
|
|
|
import Control.Concurrent.Async
|
|
|
|
import qualified Data.Map as M
|
2013-01-26 06:09:33 +00:00
|
|
|
import qualified Control.Exception as E
|
2012-10-30 18:34:48 +00:00
|
|
|
|
2013-02-06 19:38:41 +00:00
|
|
|
#ifdef WITH_WEBAPP
|
|
|
|
import Assistant.WebApp.Types
|
2013-04-04 05:48:26 +00:00
|
|
|
import Assistant.Types.Alert
|
2013-02-06 19:38:41 +00:00
|
|
|
import Assistant.Alert
|
|
|
|
import qualified Data.Text as T
|
|
|
|
#endif
|
|
|
|
|
2013-01-26 03:14:32 +00:00
|
|
|
{- Starts a named thread, if it's not already running.
|
|
|
|
-
|
|
|
|
- Named threads are run by a management thread, so if they crash
|
|
|
|
- an alert is displayed, allowing the thread to be restarted. -}
|
2013-04-03 21:44:34 +00:00
|
|
|
startNamedThread :: UrlRenderer -> NamedThread -> Assistant ()
|
assistant: Detect stale git lock files at startup time, and remove them.
Extends the index.lock handling to other git lock files. I surveyed
all lock files used by git, and found more than I expected. All are
handled the same in git; it leaves them open while doing the operation,
possibly writing the new file content to the lock file, and then closes
them when done.
The gc.pid file is excluded because it won't affect the normal operation
of the assistant, and waiting for a gc to finish on startup wouldn't be
good.
All threads except the webapp thread wait on the new startup sanity checker
thread to complete, so they won't try to do things with git that fail
due to stale lock files. The webapp thread mostly avoids doing that kind of
thing itself. A few configurators might fail on lock files, but only if the
user is explicitly trying to run them. The webapp needs to start
immediately when the user has opened it, even if there are stale lock
files.
Arranging for the threads to wait on the startup sanity checker was a bit
of a bear. Have to get all the NotificationHandles set up before the
startup sanity checker runs, or they won't see its signal. Perhaps
the NotificationBroadcaster is not the best interface to have used for
this. Oh well, it works.
This commit was sponsored by Michael Jakl
2013-10-05 21:02:11 +00:00
|
|
|
startNamedThread urlrenderer (NamedThread afterstartupsanitycheck name a) = do
|
2013-01-26 03:14:32 +00:00
|
|
|
m <- startedThreads <$> getDaemonStatus
|
|
|
|
case M.lookup name m of
|
|
|
|
Nothing -> start
|
2013-01-26 06:09:33 +00:00
|
|
|
Just (aid, _) -> do
|
|
|
|
r <- liftIO (E.try (poll aid) :: IO (Either E.SomeException (Maybe (Either E.SomeException ()))))
|
|
|
|
case r of
|
|
|
|
Right Nothing -> noop
|
|
|
|
_ -> start
|
2012-10-30 18:34:48 +00:00
|
|
|
where
|
assistant: Detect stale git lock files at startup time, and remove them.
Extends the index.lock handling to other git lock files. I surveyed
all lock files used by git, and found more than I expected. All are
handled the same in git; it leaves them open while doing the operation,
possibly writing the new file content to the lock file, and then closes
them when done.
The gc.pid file is excluded because it won't affect the normal operation
of the assistant, and waiting for a gc to finish on startup wouldn't be
good.
All threads except the webapp thread wait on the new startup sanity checker
thread to complete, so they won't try to do things with git that fail
due to stale lock files. The webapp thread mostly avoids doing that kind of
thing itself. A few configurators might fail on lock files, but only if the
user is explicitly trying to run them. The webapp needs to start
immediately when the user has opened it, even if there are stale lock
files.
Arranging for the threads to wait on the startup sanity checker was a bit
of a bear. Have to get all the NotificationHandles set up before the
startup sanity checker runs, or they won't see its signal. Perhaps
the NotificationBroadcaster is not the best interface to have used for
this. Oh well, it works.
This commit was sponsored by Michael Jakl
2013-10-05 21:02:11 +00:00
|
|
|
start
|
|
|
|
| afterstartupsanitycheck = do
|
|
|
|
status <- getDaemonStatus
|
|
|
|
h <- liftIO $ newNotificationHandle False $
|
|
|
|
startupSanityCheckNotifier status
|
|
|
|
startwith $ runmanaged $
|
|
|
|
liftIO $ waitNotification h
|
|
|
|
| otherwise = startwith $ runmanaged noop
|
|
|
|
startwith runner = do
|
2013-01-26 03:14:32 +00:00
|
|
|
d <- getAssistant id
|
assistant: Detect stale git lock files at startup time, and remove them.
Extends the index.lock handling to other git lock files. I surveyed
all lock files used by git, and found more than I expected. All are
handled the same in git; it leaves them open while doing the operation,
possibly writing the new file content to the lock file, and then closes
them when done.
The gc.pid file is excluded because it won't affect the normal operation
of the assistant, and waiting for a gc to finish on startup wouldn't be
good.
All threads except the webapp thread wait on the new startup sanity checker
thread to complete, so they won't try to do things with git that fail
due to stale lock files. The webapp thread mostly avoids doing that kind of
thing itself. A few configurators might fail on lock files, but only if the
user is explicitly trying to run them. The webapp needs to start
immediately when the user has opened it, even if there are stale lock
files.
Arranging for the threads to wait on the startup sanity checker was a bit
of a bear. Have to get all the NotificationHandles set up before the
startup sanity checker runs, or they won't see its signal. Perhaps
the NotificationBroadcaster is not the best interface to have used for
this. Oh well, it works.
This commit was sponsored by Michael Jakl
2013-10-05 21:02:11 +00:00
|
|
|
aid <- liftIO $ runner $ d { threadName = name }
|
|
|
|
restart <- asIO $ startNamedThread urlrenderer (NamedThread False name a)
|
2013-01-26 03:14:32 +00:00
|
|
|
modifyDaemonStatus_ $ \s -> s
|
2013-01-26 06:09:33 +00:00
|
|
|
{ startedThreads = M.insertWith' const name (aid, restart) (startedThreads s) }
|
assistant: Detect stale git lock files at startup time, and remove them.
Extends the index.lock handling to other git lock files. I surveyed
all lock files used by git, and found more than I expected. All are
handled the same in git; it leaves them open while doing the operation,
possibly writing the new file content to the lock file, and then closes
them when done.
The gc.pid file is excluded because it won't affect the normal operation
of the assistant, and waiting for a gc to finish on startup wouldn't be
good.
All threads except the webapp thread wait on the new startup sanity checker
thread to complete, so they won't try to do things with git that fail
due to stale lock files. The webapp thread mostly avoids doing that kind of
thing itself. A few configurators might fail on lock files, but only if the
user is explicitly trying to run them. The webapp needs to start
immediately when the user has opened it, even if there are stale lock
files.
Arranging for the threads to wait on the startup sanity checker was a bit
of a bear. Have to get all the NotificationHandles set up before the
startup sanity checker runs, or they won't see its signal. Perhaps
the NotificationBroadcaster is not the best interface to have used for
this. Oh well, it works.
This commit was sponsored by Michael Jakl
2013-10-05 21:02:11 +00:00
|
|
|
runmanaged first d = do
|
|
|
|
aid <- async $ runAssistant d $ do
|
|
|
|
void first
|
|
|
|
a
|
2013-01-26 03:14:32 +00:00
|
|
|
void $ forkIO $ manager d aid
|
|
|
|
return aid
|
|
|
|
manager d aid = do
|
2013-01-26 06:09:33 +00:00
|
|
|
r <- E.try (wait aid) :: IO (Either E.SomeException ())
|
2012-10-30 18:34:48 +00:00
|
|
|
case r of
|
|
|
|
Right _ -> noop
|
|
|
|
Left e -> do
|
2013-01-26 06:09:33 +00:00
|
|
|
let msg = unwords
|
2013-02-06 19:43:23 +00:00
|
|
|
[ fromThreadName $ threadName d
|
2013-01-26 06:09:33 +00:00
|
|
|
, "crashed:", show e
|
|
|
|
]
|
2012-10-30 18:34:48 +00:00
|
|
|
hPutStrLn stderr msg
|
2013-02-06 19:38:41 +00:00
|
|
|
#ifdef WITH_WEBAPP
|
2013-10-10 22:02:33 +00:00
|
|
|
button <- runAssistant d $ mkAlertButton True
|
2013-04-04 05:48:26 +00:00
|
|
|
(T.pack "Restart Thread")
|
|
|
|
urlrenderer
|
|
|
|
(RestartThreadR name)
|
|
|
|
runAssistant d $ void $ addAlert $
|
|
|
|
(warningAlert (fromThreadName name) msg)
|
2013-11-23 04:54:08 +00:00
|
|
|
{ alertButtons = [button] }
|
2013-02-06 19:38:41 +00:00
|
|
|
#endif
|
2013-01-26 03:14:32 +00:00
|
|
|
|
2013-01-27 11:43:05 +00:00
|
|
|
namedThreadId :: NamedThread -> Assistant (Maybe ThreadId)
|
assistant: Detect stale git lock files at startup time, and remove them.
Extends the index.lock handling to other git lock files. I surveyed
all lock files used by git, and found more than I expected. All are
handled the same in git; it leaves them open while doing the operation,
possibly writing the new file content to the lock file, and then closes
them when done.
The gc.pid file is excluded because it won't affect the normal operation
of the assistant, and waiting for a gc to finish on startup wouldn't be
good.
All threads except the webapp thread wait on the new startup sanity checker
thread to complete, so they won't try to do things with git that fail
due to stale lock files. The webapp thread mostly avoids doing that kind of
thing itself. A few configurators might fail on lock files, but only if the
user is explicitly trying to run them. The webapp needs to start
immediately when the user has opened it, even if there are stale lock
files.
Arranging for the threads to wait on the startup sanity checker was a bit
of a bear. Have to get all the NotificationHandles set up before the
startup sanity checker runs, or they won't see its signal. Perhaps
the NotificationBroadcaster is not the best interface to have used for
this. Oh well, it works.
This commit was sponsored by Michael Jakl
2013-10-05 21:02:11 +00:00
|
|
|
namedThreadId (NamedThread _ name _) = do
|
2013-01-27 11:43:05 +00:00
|
|
|
m <- startedThreads <$> getDaemonStatus
|
|
|
|
return $ asyncThreadId . fst <$> M.lookup name m
|
|
|
|
|
2013-01-26 06:09:33 +00:00
|
|
|
{- Waits for all named threads that have been started to finish.
|
|
|
|
-
|
|
|
|
- Note that if a named thread crashes, it will probably
|
|
|
|
- cause this to crash as well. Also, named threads that are started
|
|
|
|
- after this is called will not be waited on. -}
|
2013-01-26 03:14:32 +00:00
|
|
|
waitNamedThreads :: Assistant ()
|
|
|
|
waitNamedThreads = do
|
|
|
|
m <- startedThreads <$> getDaemonStatus
|
2013-01-26 06:09:33 +00:00
|
|
|
liftIO $ mapM_ (wait . fst) $ M.elems m
|
2013-01-26 03:14:32 +00:00
|
|
|
|