RE: [cdt-dev] The Spawner...

[Doug Schaefer <DSchaefer@xxxxxxx>]

One thing I'm looking at is moving away from using the Spawner for
everything other than debug. Debug is the only app that currently relies on
interrupts.

How does the Java Runtime.exec handle these situations?

Doug Schaefer, QNX Software Systems
Eclipse CDT Project Lead, http://cdtdoug.blogspot.com

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Robert Norton
> Sent: Tuesday, November 20, 2007 9:27 AM
> To: CDT General developers list.
> Subject: RE: [cdt-dev] The Spawner...
> 
> Perhaps the solution would for Spawner to send SIGINT, then SIGTERM,
> then SIGKILL? This would give the process the best chance of terminating
> cleanly. Another problem is that the one second timeout is totally
> arbitrary -- plenty of process will take longer than that to clean up...
> 
> Robert
> 
> P.S.
> 
> On an unrelated note I shudder every time I see this sort of thing:
> 
> try {
> ...
> } catch (IOException e) {
> }
> 
> If you're not expecting an exception and don't want to handle it, at
> least log it so that it isn't completely hidden from sight! A simple:
> 
> MyPlugin.getDefault().log(e)
> 
> will do the trick if a suitable MyPlugin class is defined, and it could
> be the clue which helps someone to spot / fix a bug. Of course this
> doesn't apply if an exception IS expected and doing nothing is the
> correct behaviour (in which case a comment would be nice).
> 
> > -----Original Message-----
> > From: cdt-dev-bounces@xxxxxxxxxxx
> > [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Christopher Mead
> > Sent: 20 November 2007 13:49
> > To: CDT General developers list.
> > Subject: [cdt-dev] The Spawner...
> >
> > Hi folks,
> >
> > Targetting the CDT MakeFile project at a custom build tool
> > (invoked from
> > the command line) I noticed that when one presses "cancel"
> > (on Windows)
> > that the process is unceremoniously killed (as in Unix style kill -9),
> > the problem we jave with that is that our custom build tool gets no
> > opportunity to unroll state (mapped drives, locks etc.).  The
> > following
> > code is that which does the process killing:
> >
> >
> > Spawner.java  (org.eclipse.cdt.utils.spawner):
> >
> > 	public synchronized void destroy()
> > 	{
> > 		// Sends the TERM
> > 		terminate();
> > 		// Close the streams on this side.
> > 		try {
> > 			if(null == err)
> >
> > ((SpawnerInputStream)getErrorStream()).close();
> > 			if(null == in)
> >
> > ((SpawnerInputStream)getInputStream()).close();
> > 			if(null == out)
> >
> > ((SpawnerOutputStream)getOutputStream()).close();
> > 		} catch (IOException e) {
> > 		}
> > 		// Grace before using the heavy gone.
> > 		if (!isDone) {
> > 			try {
> > 				wait(1000);
> > 			} catch (InterruptedException e) {
> > 			}
> > 		}
> > 		if (!isDone) {
> > 			kill();
> > 		}
> > 	}
> >
> > 	public int kill() {
> > 		return raise(pid, KILL);
> > 	}
> >
> > 	public int terminate() {
> > 		return raise(pid, TERM);
> > 	}
> >
> >
> >
> >
> > I understand the intention is to do a soft kill (equivalent
> > to sending a
> > TERM signal in unix) and if that fails then to do a "kill -9" style
> > kill.  All very well.  Except that the Windows JNI code that
> > implements
> > 'raise' does the following (I have excerpted the relavant code from
> > Win32ProcessEx.c and excised the debug code):
> >
> > .
> > .
> > .
> > 	switch(signal)
> > 		{
> > 		case SIG_NOOP:
> > 			// Wait 0 msec -just check if the process has
> > been still running
> > 			ret = ((WAIT_TIMEOUT ==
> > WaitForSingleObject(hProc, 0)) ? 0 : -1);
> > 			break;
> > 		case SIG_HUP:
> > 			// Temporary do nothing
> > 			ret = 0;
> > 			break;
> > 		case SIG_KILL:
> > 		case SIG_TERM:
> > 		    SetEvent(pCurProcInfo -> eventTerminate);
> > 			ret = 0;
> > 			break;
> > 		case SIG_INT:
> > 		    ResetEvent(pCurProcInfo -> eventWait);
> > 			PulseEvent(pCurProcInfo -> eventBreak);
> > 			ret = (WaitForSingleObject(pCurProcInfo ->
> > eventWait, 100) == WAIT_OBJECT_0);
> > 			break;
> > 		default:
> > 			break;
> > 		}
> > .
> > .
> > .
> >
> > So Windows treats the KILL and TERM signals identically!  Is
> > this truly
> > the correct way of doing things?  This code doesn't seem to be really
> > reflecting intended purpose of the Spawner (Java) code above.  Ought I
> > raise this as a defect?
> >
> > Personally I found that replacing the TERM constant from "raise(pid,
> > TERM)" with a number corresponding to SIG_INT (2 according to the enum
> > in Win32ProcessEx.c) did the job as far as my problems were concerned,
> > how this impacts on other usage of the Spawner I'm not sure.
> >
> > Regards,
> >
> > Chris Mead.
> >
> > ====================================
> > Chris Mead - Software Engineer - ARM
> > Cambridge - England
> > Phone: +44 1223 406 317
> > Email: christopher.mead@xxxxxxx
> >
> > --
> > IMPORTANT NOTICE: The contents of this email and any
> > attachments are confidential and may also be privileged. If
> > you are not the intended recipient, please notify the sender
> > immediately and do not disclose the contents to any other
> > person, use it for any purpose, or store or copy the
> > information in any medium.  Thank you.
> >
> >
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> >
> >
> 
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev