Re: runProcess+removeFile, Windows, possibly finaliser not running

On 11/17/05, Simon Marlow <simonmar@xxxxxxxxxxxxx> 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.c        13 Aug 2004 13:11:23 -0000      1.3
+++ ghc/utils/prof/cgprof/main.c        17 Nov 2005 05:23:08 -0000
@@ -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