[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] The Spawner...
|
FWIW, if you cancel a (potentially) recursive make process, make is able
to still clean up its temporary files, before the whole process tree is
killed. Thus, I guess the problem should be solved in your custom build
tool in a similar manner, rather than changing the CDT spawner.
Cheers,
Walter
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Robert Norton
> Sent: Dienstag, 20. November 2007 15:27
> 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
>
