[M3devel] [M3commit] CVS Update: cm3

Mon Feb 21 04:46:04 CET 2011

Ok, it looks like I did break it.

http://modula3.elegosoft.com/cgi-bin/cvsweb.cgi/cm3/m3-libs/libm3/src/os/WIN32/ProcessWin32.m3.diff?r1=1.6;r2=1.7

GetID used to return the handle. I changed it to return the id.

m3middle/Process.Abort LOOPHOLEs GetID to a handle.

I think the GetID change should probably stay. But certainly one or the other must change.

The handle is not unique across the system, just the process, whereas the id is unique across the system.

If Process.i3 only mandates within the process, then maybe the old way. Maybe.

 - Jay

From: jay.krell at cornell.edu
To: mika at async.caltech.edu
Date: Mon, 21 Feb 2011 03:28:10 +0000
CC: m3devel at elegosoft.com
Subject: Re: [M3devel] [M3commit] CVS Update: cm3

Wait? No, that is probably just bogus posix thinking.
You can just close your handle to the process.
You don't have to wait for it to exit.

It is somewhat orthogonal.
The thing is, the request for Process.Kill, got me looking at when
does libm3 close the Process handle and when does it use the
handle correctly (i.e. not m3middle's Process.Abort!)
It does the CloseHandle in Process.Wait, so if that is never called, there is a leak.

Anyway, this should be easy to make correct.
  (So easy, though, it boggles the mind as to why it was done this way
  in the first place. I do have to check somethig -- it is SLIGHTLY possible I broke it.
  I know I fiddled around with the definition of process ids, made them match
  the underlying platform. I'll check the history. m3middle uses a LOOPHOLE
  on some "id" to get the "handle". Anyway, I'll check and make it correct.)

 - Jay

> To: jay.krell at cornell.edu
> Date: Sun, 20 Feb 2011 17:15:50 -0800
> From: mika at async.caltech.edu
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] [M3commit] CVS Update: cm3
> 
> 
> Jay I didn't quite follow your previous messages. What is the correct
> solution, and what did you mean when you were talking about the garbage
> collector? It does seem like---if a Process handle goes out of scope
> and gets collected then yes the runtime should do the equivalent of "EVAL
> Process.Wait" at some future time. But that seems unrelated/orthogonal
> to the issues with the Windows process killing...
> 
> The process killing in m3middle/M3Process I think is only called in
> a few places in the compiler and then under what already are dubious
> circumstances. For instance I see it done where Process.Create has
> failed. But if Process.Create has failed, then there's no process to
> kill, so it all seems rather pointless. It is also called as one of
> the last actions before exiting the parent process, so there's another
> reason for its being pointless.
> 
> In other words I think it's safe to say that if you have an idea for
> how to implement process-killing correctly on Windows you can do it
> however you like without fear of breaking any existing code...
> 
> Mika
> 
> But I can 
> 
> Jay K writes:
> >--_d36c70d3-e71b-433d-abdc-06703a929f89_
> >Content-Type: text/plain; charset="iso-8859-1"
> >Content-Transfer-Encoding: quoted-printable
> >
> >
> >The code here confuses hProcess and dwProcessId.
> >Can we introduce a public function here in libm3 instead of m3middle?
> >ie: to avoid answering the question as to how to expose hProcess?
> >And to avoid the loophole as well?
> >
> >Thanks=2C
> > - Jay
> >
> >From: jay.krell at cornell.edu
> >To: jkrell at elego.de=3B m3commit at elegosoft.com
> >Subject: RE: [M3commit] CVS Update: cm3
> >Date: Mon=2C 21 Feb 2011 00:35:38 +0000
> >
> >
> >
> >
> >
> >
> >
> >
> >Hm. Actually=2C Win32 is not broken=2C but libm3/m3middle are clearly incor=
> >rect here.
> >
> > - Jay
> >
> >> Date: Mon=2C 21 Feb 2011 01:32:47 +0000
> >> To: m3commit at elegosoft.com
> >> From: jkrell at elego.de
> >> Subject: [M3commit] CVS Update: cm3
> >>=20
> >> CVSROOT: /usr/cvs
> >> Changes by: jkrell at birch. 11/02/21 01:32:47
> >>=20
> >> Modified files:
> >> cm3/m3-sys/m3middle/src/: M3Process.i3=20
> >>=20
> >> Log message:
> >> remove incorrect comments=3B Win32 is not broken
> >>=20
> > =
> >
> >--_d36c70d3-e71b-433d-abdc-06703a929f89_
> >Content-Type: text/html; charset="iso-8859-1"
> >Content-Transfer-Encoding: quoted-printable
> >
> ><html>
> ><head>
> ><style><!--
> >.hmmessage P
> >{
> >margin:0px=3B
> >padding:0px
> >}
> >body.hmmessage
> >{
> >font-size: 10pt=3B
> >font-family:Tahoma
> >}
> >--></style>
> ></head>
> ><body class=3D'hmmessage'>
> >The code here confuses hProcess and dwProcessId.<br>Can we introduce a publ=
> >ic function here in libm3 instead of m3middle?<br>ie: to avoid answering th=
> >e question as to how to expose hProcess?<br>And to avoid the loophole as we=
> >ll?<br><br>Thanks=2C<br>&nbsp=3B- Jay<br><br><hr id=3D"stopSpelling">From: =
> >jay.krell at cornell.edu<br>To: jkrell at elego.de=3B m3commit at elegosoft.com<br>S=
> >ubject: RE: [M3commit] CVS Update: cm3<br>Date: Mon=2C 21 Feb 2011 00:35:38=
> > +0000<br><br>
> >
> ><meta http-equiv=3D"Content-Type" content=3D"text/html=3B charset=3Dunicode=
> >">
> ><meta name=3D"Generator" content=3D"Microsoft SafeHTML">
> ><style>
> >.ExternalClass .ecxhmmessage P
> >{padding:0px=3B}
> >.ExternalClass body.ecxhmmessage
> >{font-size:10pt=3Bfont-family:Tahoma=3B}
> >
> ></style>
> >
> >
> >Hm. Actually=2C Win32 is not broken=2C but libm3/m3middle are clearly incor=
> >rect here.<br><br>&nbsp=3B- Jay<br><br>&gt=3B Date: Mon=2C 21 Feb 2011 01:3=
> >2:47 +0000<br>&gt=3B To: m3commit at elegosoft.com<br>&gt=3B From: jkrell at eleg=
> >o.de<br>&gt=3B Subject: [M3commit] CVS Update: cm3<br>&gt=3B <br>&gt=3B CVS=
> >ROOT: /usr/cvs<br>&gt=3B Changes by: jkrell at birch. 11/02/21 01:32:47<br>&gt=
> >=3B <br>&gt=3B Modified files:<br>&gt=3B cm3/m3-sys/m3middle/src/: M3Proce=
> >ss.i3 <br>&gt=3B <br>&gt=3B Log message:<br>&gt=3B remove incorrect commen=
> >ts=3B Win32 is not broken<br>&gt=3B <br> </body>
> ></html>=
> >
> >--_d36c70d3-e71b-433d-abdc-06703a929f89_--

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20110221/13ad8d18/attachment-0002.html>