summaryrefslogtreecommitdiff
path: root/Utility/CoProcess.hs
Commit message (Collapse)AuthorAge
* relicense general utility library code to BSDGravatar Joey Hess2014-05-10
| | | | | Omitted a couple of files what have had significant contributions from others.
* hlintGravatar Joey Hess2014-04-26
|
* Avoid looping if long-running git cat-file or git hash-object crashes and ↵Gravatar Joey Hess2014-01-01
| | | | keeps crashing when restarted.
* get rid of __WINDOWS__, use mingw32_HOST_OSGravatar Joey Hess2013-08-02
| | | | | The latter is harder for me to remember, but avoids build failures in code used by the configure program.
* got file descriptors mixed up in last commitGravatar Joey Hess2013-06-14
|
* Windows: Fix hang when adding several files at once.Gravatar Joey Hess2013-06-14
|
* Can now restart certain long-running git processes if they crash, and ↵Gravatar Joey Hess2013-05-31
| | | | | | | | | | | | | | | | | | | continue working. Fuzz tests have shown that git cat-file --batch sometimes stops running. It's not yet known why (no error message; repo seems ok). But this is something we can deal with in the CoProcess framework, since all 3 types of long-running git processes should be restartable if they fail. Note that, as implemented, only IO errors are caught. So an error thrown by the reveiver, when it sees something that is not valid output from git cat-file (etc) will not cause a restart. I don't want it to retry if git commands change their output or are just outputting garbage. This does mean that if the command did a partial output and crashed in the middle, it would still not be restarted. There is currently no guard against restarting a command repeatedly, if, for example, it crashes repeatedly on startup.
* refactoringGravatar Joey Hess2013-05-11
|
* run git coprocesses with gitEnvGravatar Joey Hess2012-09-15
|
* add back debug loggingGravatar Joey Hess2012-07-19
| | | | | | | | | | | | | Make Utility.Process wrap the parts of System.Process that I use, and add debug logging to them. Also wrote some higher-level code that allows running an action with handles to a processes stdin or stdout (or both), and checking its exit status, all in a single function call. As a bonus, the debug logging now indicates whether the process is being run to read from it, feed it data, chat with it (writing and reading), or just call it for its side effect.
* switch from System.Cmd.Utils to System.ProcessGravatar Joey Hess2012-07-18
| | | | | | | | | | | | | | | | | | Test suite now passes with -threaded! I traced back all the hangs with -threaded to System.Cmd.Utils. It seems it's just crappy/unsafe/outdated, and should not be used. System.Process seems to be the cool new thing, so converted all the code to use it instead. In the process, --debug stopped printing commands it runs. I may try to bring that back later. Note that even SafeSystem was switched to use System.Process. Since that was a modified version of code from System.Cmd.Utils, it needed to be converted too. I also got rid of nearly all calls to forkProcess, and all calls to executeFile, which I'm also doubtful about working well with -threaded.
* refactorGravatar Joey Hess2012-02-20