Ticket #3243: 1242387095.dpatch

File 1242387095.dpatch, 5.7 KB (added by nwn, 6 years ago)

patch to this bug, It works fine and passes tests

1Fri May 15 20:29:51 JST 2009  Yusaku Hashimoto <[email protected]>
2  * before fork(), stopTimer() for child process, after fork(), startTimer() for parent process
4New patches:
6[before fork(), stopTimer() for child process, after fork(), startTimer() for parent process
7Yusaku Hashimoto <[email protected]>**20090515112951] {
8hunk ./cbits/runProcess.c 66
9     // shared between parent and child), and the parent behaves as if
10     // the signal had been raised.
11     blockUserSignals();
12+       stopTimer();
14     switch(pid = fork())
15     {
16hunk ./cbits/runProcess.c 71
17     case -1:
18+               startTimer();
19         unblockUserSignals();
20         if (fdStdIn == -1) {
21             close(fdStdInput[0]);
22hunk ./cbits/runProcess.c 189
23         }
24        break;
25     }
26+       startTimer();
27     unblockUserSignals();
29     return pid;
34[Remove some incorrect (out of date?) documentation; fixes trac #3152
35Ian Lynagh <[email protected]>**20090410173535]
36[fix this test for MSYS
37Simon Marlow <[email protected]>**20090310130059]
38[Avoid vfork() bear traps
39Simon Marlow <[email protected]>**20090309161943
40 Ignore-this: db3593f7e5db1db560842c729e47c551
41 We can't call setIOManagerPipe() in the vfork() child, because the
42 change will be reflected in the parent too.  Add a large warning to
43 that effect.
45 I tried changing vfork() to fork(), but it seems that this leads to a
46 different problem: the fork() sometimes takes so long that it gets
47 repeatedly interrupted by the timer signal and never makes progress.
48 I could disable the timer for a while, but decided to back off and fix
49 the vfork() version instead.
51[fix documentation for termianteProcess (#2954)
52Simon Marlow <[email protected]>**20090305145745
53 Ignore-this: 341860d041d9dd7345f41dec64de0be7
55[Add config.guess, config.sub and install-sh
56Ian Lynagh <[email protected]>**20090307153856]
57[Fix #2870: User signals are not blocked before 'fork' in runInteractiveProcess
58Simon Marlow <[email protected]>**20090219123235
59 Ignore-this: dd132c40e9ccefc8362caf44216a81a0
61[Require Cabal version >= 1.6
62Ian Lynagh <[email protected]>**20090122011323]
63[Add "bug-reports" and "source-repository" info to the Cabal file
64Ian Lynagh <[email protected]>**20090121182651]
65[Avoid using IOError internals
66Ian Lynagh <[email protected]>**20090104173211]
67[fix warning on Windows
68Simon Marlow <[email protected]>**20081114124114]
69[add some extra_clean
70Simon Marlow <[email protected]>**20081114104354]
72Simon Marlow <[email protected]>**20081114104329]
73[Pass the correct name to runGenProcess_ for sake of error messages
74Duncan Coutts <[email protected]>**20081113105602
75 Otherwise error messages from calling createProcess will report the
76 internal name runGenProcess_ which is misleading. Similarly for the
77 system and rawSystem functions.
79[remove non-existent autoconf files from extra-source-files
80Simon Marlow <[email protected]>**20081112125459]
81[fix .cabal style bugs noticed by Cabal 1.6
82Simon Marlow <[email protected]>**20081105100456]
83[a Windows fix, and a base-4 fix
84Simon Marlow <[email protected]>**20081024135423]
85[improve docs for terminateProcess (#2638)
86Simon Marlow <[email protected]>**20081024134725
87 When used with a shell command on Windows, terminateProcess only kills
88 the shell, not the command.
90[Make this compile with ghc-6.8.3; update version to
91Simon Marlow <[email protected]>**20081023143737]
92[Use printf rather than echo for the process008 test
93Ian Lynagh <[email protected]>**20081001232339
94 It doesn't work on Windows for me otherwise
96[Bump version number to
97Ian Lynagh <[email protected]>**20080920160210]
98[TAG 6.10 branch has been forked
99Ian Lynagh <[email protected]>**20080919123438]
100[follow library changes
101Ian Lynagh <[email protected]>**20080903223613]
102[non-GHC: export System.Process, not System.Process.Internals
103Ross Paterson <[email protected]>**20080831181126]
104[fix cabal build-depends for nhc98
105[email protected]**20080828104512]
106[add category field
107Ross Paterson <[email protected]>**20080824003013]
108[add extra-source-files
109Ross Paterson <[email protected]>**20080824002709]
110[We now depend on concurrent (split off from base)
111Ian Lynagh <[email protected]>**20080824135154]
112[use fmap instead of importing Applicative
113Ross Paterson <[email protected]>**20080817001800
115 Importing Applicative into this module causes the instances in
116 Control.Monad.Instances to leak into the Haskell 98 module System,
117 which would break Haskell 98 programs that define these instances.
119[switch to new exceptions
120Ross Paterson <[email protected]>**20080814150115]
121[Windows fix
122Ian Lynagh <[email protected]>**20080803180419]
123[We don't need to explicitly "import Prelude"
124Ian Lynagh <[email protected]>**20080803152344
125 We had to do this beofre to ensure that things built in the right order,
126 but now Prelude is in a different package.
128[Follow extensible exceptions changes
129Ian Lynagh <[email protected]>**20080623193127]
130[Silence warnings
131Ian Lynagh <[email protected]>**20080703154751]
132[Fix warnings
133Ian Lynagh <[email protected]>**20080620011826]
134[Avoid using deprecated flags
135Ian Lynagh <[email protected]>**20080616145419]
136[turn off new functions for Hugs (for now)
137Ross Paterson <[email protected]>**20080615224631]
138[try to make this test a bit more portable (don't depend on the output of ls)
139Simon Marlow <[email protected]>**20080604092520]
140[update Windows output
141Simon Marlow <[email protected]>**20080529153428]
142[fix bug on Windows when redirecting stderr
143Simon Marlow <[email protected]>**20080529153316]
144[readProcessWithExitCode now returns separate stdout & stderr
145Simon Marlow <[email protected]>**20080528103212]
146[TAG 2008-05-28
147Ian Lynagh <[email protected]>**20080528004421]
148Patch bundle hash: