| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
| |
Or until hackage stops rejecting os(gnu), if it is indeed the right name..
|
| | |
|
| | |
|
| |
|
|
| |
yesod, or the new version of warp seem to have a bug that causes the webapp to hang.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This is a compromise. I would like to nice every thread except for the
webapp thread, but it's not practical to do so. That would need every
thread to run as a bound thread, which could add significant overhead.
And any forkIO would escape the nice level.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Will be re-releasing the last version to hackage with a .1 with this fix.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
catching exceptions.
As seen in this bug report, the lifted exception handling using the StateT
monad throws away state changes when an action throws an exception.
http://git-annex.branchable.com/bugs/git_annex_fork_bombs_on_gpg_file/
.. Which can result in cached values being redundantly calculated, or other
possibly worse bugs when the annex state gets out of sync with reality.
This switches from a StateT AnnexState to a ReaderT (MVar AnnexState).
All changes to the state go via the MVar. So when an Annex action is
running inside an exception handler, and it makes some changes, they
immediately go into affect in the MVar. If it then throws an exception
(or even crashes its thread!), the state changes are still in effect.
The MonadCatchIO-transformers change is actually only incidental.
I could have kept on using lifted-base for the exception handling.
However, I'd have needed to write a new instance of MonadBaseControl
for the new monad.. and I didn't write the old instance.. I begged Bas
and he kindly sent it to me. Happily, MonadCatchIO-transformers is
able to derive a MonadCatchIO instance for my monad.
This is a deep level change. It passes the test suite! What could it break?
Well.. The most likely breakage would be to code that runs an Annex action
in an exception handler, and *wants* state changes to be thrown away.
Perhaps the state changes leaves the state inconsistent, or wrong. Since
there are relatively few places in git-annex that catch exceptions in the
Annex monad, and the AnnexState is generally just used to cache calculated
data, this is unlikely to be a problem.
Oh yeah, this change also makes Assistant.Types.ThreadedMonad a bit
redundant. It's now entirely possible to run concurrent Annex actions in
different threads, all sharing access to the same state! The ThreadedMonad
just adds some extra work on top of that, with its own MVar, and avoids
such actions possibly stepping on one-another's toes. I have not gotten
rid of it, but might try that later. Being able to run concurrent Annex
actions would simplify parts of the Assistant code.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This is enough to let the configure program build.
|
| |
|
|
| |
build.
|
| |
|
|
| |
built. This may fix builds on s390x and sparc, which are failing to link -lHSrts_thr
|
| |
|
|
|
| |
Presumably, if the filesystem doesn't support file permissions, it's not
much of a multiuser system.
|
| |
|
|
| |
with, since yesod 1.2 has a great many changes that will require extensive work on the webapp.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
That is very dodgy; it makes *every* C file compiled have that header added
to it. Apparently sys/event.h needs some other header files to be included
on some OS's, and so this leads to compile failures in completely unrelated
places to the code that actually uses sys/event.h
This reverts commit a767040a53182cde16434cba686252bbaf776cf9, which added
this with no rationalle and I must have missed in amoung the other patches
when merging.
Also, Utility/kqueue.c already includes sys/event.h
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
This will make it easier to use the Evil Splicer, when it needs to add
package qualified imports
And there's no real downside.
|
| |
|
|
|
|
|
| |
connecting to it from another.
Does not yet use HTTPS. I'd need to generate a certificate, and I'm not
sure what's the best way to do that.
|
| | |
|
| |
|
|
| |
attached
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
rather buggy.
|
| |
|
|
| |
rm was blocked waiting for input
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
explicitly specified
The current use of the 'Fast' and 'Production' flags is both inconsistent and
redundant. It's inconsistent, because users are allowed to specify both '-fFast
-fProduction' at the same time -- thereby enabling two contradicting features.
The flags are redundant, because Cabal allows users to specify '-O0' at
configure time, which is essentially the same as '-fFast'. Since 'Production'
is just the opposite of 'Fast', this means that neither flag is needed.
|
| |
|
|
| |
building on BSD
|
Joey Hess
Peter Simons
Joey Hess
Peter Simons