Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] [DSF] GDBBackend.MonitorJob.kill not working? 
On 19/04/12 18:12, Marc Khouzam wrote:

-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx
[mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Vladimir Prus
Sent: Thursday, April 19, 2012 9:49 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] [DSF] GDBBackend.MonitorJob.kill not working?

On 19/04/12 17:43, Marc Khouzam wrote:

Hi,

I have to agree this seems suspicious, but in the end it works.
Inside the call to run(IProgressMonitor monitor), there is

a call that

you didn't show in your mail:

     fMonProcess.waitFor();

this in turn calls wait() which releases the lock on fMonProcess.


But it does not seem like Process.waitFor is documented to do that?


Process.waitFor() is abstract and implemented by CDT's Spawner.waitFor()

	@Override
	public synchronized int waitFor() throws InterruptedException {
		while (!isDone) {
			wait();
		}
             ...
      }



I've actually tried it and things work as expected.
I'm not sure if this was thought out properly or if we got lucky :)


Did you actually saw 'interrupt' working? For me, -gdb-exit
is sent to GDB,
which promptly exits, and waitFor is done. I could not even
get 'kill' to be called.


I expected that, so I hacked the code to call kill() when pressing
some UI button.  Then I saw that the running monitor job was
interrupted.  It was to make sure the fMonProcess monitor was
not still owned by the job.


I see, thanks for explanation! [Now, this means we still have a better-hidden
race condition to find somewhere in this code, but that's for another day].


--
Vladimir Prus
CodeSourcery / Mentor Graphics
http://www.mentor.com/embedded-software/

Back to the top