Conversation
The deadline of a test only interrupts its thread and never joins it, while nothing in dataization ever polled the interrupt flag. Every test the deadline skipped therefore left a thread spinning for the rest of the fork, starving the runner until the whole job was cancelled. PhDefault.take() now throws ExInterrupted when the current thread carries the flag. The flag stays up, so every next lookup fails the same way and no try can resurrect the computation.
|
There was a problem hiding this comment.
Pull request overview
This PR ensures EO dataization stops promptly when a JUnit timeout interrupts the executing thread, preventing runaway computations from leaking long-lived junit-timeout-thread-* threads during eo.deadline-skipped tests.
Changes:
- Add an interrupt-flag guard in
PhDefault.take()that throwsExInterruptedon the next attribute lookup. - Introduce
ExInterruptedas a dedicated runtime exception for interrupted-thread dataization. - Add
ExInterruptedTestto reproduce/validate that interrupted attribute lookup terminates the computation thread.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| eo-runtime/src/main/java/org/eolang/PhDefault.java | Checks Thread.currentThread().isInterrupted() in take() and aborts dataization by throwing ExInterrupted. |
| eo-runtime/src/main/java/org/eolang/ExInterrupted.java | Adds a new exception type used to terminate interrupted-thread computations. |
| eo-runtime/src/test/java/org/eolang/ExInterruptedTest.java | Adds a regression test ensuring interrupted attribute lookup stops promptly. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| /** | ||
| * Ctor. | ||
| * @param cause Exception cause | ||
| */ | ||
| public ExInterrupted(final String cause) { | ||
| super(cause); | ||
| } |
🚀 Performance AnalysisAll benchmarks are within the acceptable range. No critical degradation detected (threshold is 100%). Please refer to the detailed report for more information. Click to see the detailed report
|
|
These counts changed in this branch,
They are defined in .github/workflows/counts.yml |
|
@yegor256 Thanks for the contribution! You've earned +8 points for this: +16 as a basis; -8 for the lack of code review. Please, keep them coming. Your running score is +2882; don't forget to check your Zerocracy account too). |
A test that outlives
eo.deadlinegets skipped, but its work does not stop: JUnit interrupts the thread and never joins it, and nothing in dataization ever looked at the interrupt flag.PhDefault.take()now checks it and throws the newExInterruptedon the very next attribute lookup. The flag is read, not cleared, so every later lookup fails the same way and an EO-leveltrycannot bring the computation back to life.Without this, every skipped test left a non-daemon
junit-timeout-threadspinning for the rest of the fork. They pile up, starve the runner, and then tests that need a few hundred milliseconds start overrunning their wall-clock deadline too and leak threads of their own — which is how theruntimejob ends up skipping whole classes at once and getting cancelled at the 30-minute limit. With a 1s deadline, eight endless dataizations used to leave eight live threads behind; now they leave none.ExInterruptedTestreproduces it: without the guard the interrupted thread is still taking attributes when the test gives up on it.One thing to keep in mind: the deadline is still measured in wall clock under parallel execution, so
eo.deadline=1will keep skipping tests that are merely slow rather than stuck. That value probably wants raising, but it is a separate decision.Closes #6670