RE: runProcess+removeFile, Windows, possibly finaliser not running
On 17 November 2005 04:06, Esa Ilari Vuokko wrote: Fine, I removed usage of sleep in some profiler thingy, so it compiled and I could continue with build. where exactly? I haven't seen this. But when build get to the point compiling Network.Socket (I think), hsc2hs barfed permission denied-error (even on repeated attempts) when (apparently) removing temporary executable it had created. Well, my fix was to use try $ removeFile foo, slightly unoptimal solution ;-) Because error was permission problem, there isn't much choice why it happens - running process in Windows locks executable while there is an unclosed handle to it. It is apparent that libraries/base/System/Internals.hs, line 106 forward mkProcessHandle :: PHANDLE - IO ProcessHandle mkProcessHandle h = do ioref - newIORef h mkWeakIORef ioref (c_CloseHandle h) return (ProcessHandle ioref) attaches some sort of finaliser to it (why it's done this way?). I made this change recently so that repeated calls to waitForProcess or terminateProcess would be possible without getting an error about closed handles. I've just improved it so that the handle is now closed eagerly, but still finalized if it isn't referenced. This should fix the hsc2hs problem (which incedentally I couldn't reproduce for some reason). The only sensible solution that springs to mind is to broaden handle to contain space for exit code for process (or whatever information is required) and on call to waitProcess/getProcessExitCode gather this information, close the handle and change the handle to INVALID_HANDLE. Also, finaliser would need to ignore such handle, as closing handle twice is error (possibly also dangerous if handles can rotate, but I don't know if that is possible). yes, this is pretty much what I did. Cheers, Simon ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: runProcess+removeFile, Windows, possibly finaliser not running
On 11/17/05, Simon Marlow [EMAIL PROTECTED] wrote:
On 17 November 2005 04:06, Esa Ilari Vuokko wrote:
Fine, I removed usage of sleep in some profiler thingy, so it compiled
and I could continue with build.
where exactly? I haven't seen this.
Wierd.
Index: ghc/utils/prof/cgprof/main.c
===
RCS file: /cvs/fptools/ghc/utils/prof/cgprof/main.c,v
retrieving revision 1.3
diff -u -r1.3 main.c
--- ghc/utils/prof/cgprof/main.c13 Aug 2004 13:11:23 - 1.3
+++ ghc/utils/prof/cgprof/main.c17 Nov 2005 05:23:08 -
@@ -115,7 +115,7 @@
/* printf(Initialisation done\n); */
- if (Verbose) sleep(10);
+ /*if (Verbose) sleep(10); */
if (!(fptr=fopen(ProfileData,r))) {
fprintf(stderr,%s: unable to open profile data in \%s\.\n%s\n,
Pgm,ProfileData,usage);
attaches some sort of finaliser to it (why it's done this way?).
I made this change recently so that repeated calls to waitForProcess or
terminateProcess would be possible without getting an error about closed
handles.
Ah.
I've just improved it so that the handle is now closed eagerly, but
still finalized if it isn't referenced. This should fix the hsc2hs
problem (which incedentally I couldn't reproduce for some reason).
Worst kind of bugs :-(
The only sensible solution that springs to mind is to broaden handle
to contain space for exit code for process (or whatever information is
required) and on call to waitProcess/getProcessExitCode gather this
information, close the handle and change the handle to INVALID_HANDLE.
Also, finaliser would need to ignore such handle, as closing handle
twice is error (possibly also dangerous if handles can rotate, but I
don't know if that is possible).
yes, this is pretty much what I did.
Thanks!
--Esa
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
