Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[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.




Back to the top