On 11/22/11 06:56 PM, Alan Bateman wrote:
On 22/11/2011 17:22, Neil Richards wrote:
:
Can you tell me, when jtreg decides to fire an interrupt at a test, has
it already concluded that the test has "failed" (or, at least, not
"passed") ?
With othervm (the default) then each test is run in its own VM so the
process termination will ensure that everything is cleaned up. With
agentvm mode then tests are run sequentially in the same VM (or a pool
VMs). In that case then jtreg gives each test its own ThreadGroup. When
the test completes then it checks the thread group for any non-daemon
threads and interrupts them with the hope that they will terminate in a
timely manner. If they don't terminate within a short time then the test
fails with an error. With the original test then the thread was a daemon
thread which is why we didn't notice a problem. With your updated test
then the thread terminates before the test completes so there shouldn't
be a problem. Chris's concern comes in in the event that the test
doesn't complete (it hangs for example), in which case jtreg will
attempt to interrupt the remaining threads before giving up. In agent VM
mode this just means the agent (process) will terminate and it spins up
a new agent process to replace it.
Right, and I was proposing that any threads created by the test be
interruptible and be able to terminate in a timely manner.
I don't think in this case throwing from the catch block of IE is
necessary, just that the thread terminate quickly. It is not relevant to
the testing of the original bug. Make sense?
-Chris.
-Alan.
