[Bug 64] New: Thread.interrupt() and co. unreliable/dangerous/buggy

http://sablevm.org/bugs/show_bug.cgi?id=64

           Summary: Thread.interrupt() and co. unreliable/dangerous/buggy
           Product: SableVM
           Version: staging
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: default
        AssignedTo: [email protected]
        ReportedBy: [email protected]
         QAContact: [email protected]


Practice shows that current implementation has deadlock conditions.
This was observed while resizing an AWT window.

We should also make sure we don't throw InterruptedException
from places when it is not expected (like synchronized methods
entry/leave).  Not sure if it's the case at the moment.

It should also be checked with specs when "interrupted" flag
should be cleared, i.e. in case of subsequent calls to interrupt().

Ideas:
* We have a machine word on which we can operate with C&S
* This word contains flags: "interrupted" and "throw exception"
* This word also contains index of fatlock on which a thread
is expected to be sleeping (similarly to value in object lockword)
This index is only changed by the target thread itself when
it enters/leaves wait() on a fatlock.  On enter/leave to wait()
thread also checks "throw exception" flag.  If it was set it
clears it and throws an exception.  It does the same when it
"unexpectedly" wakes up from fat lock (because it was interrupt()ed).
* interrupting thread atomically checks fatlock index and
- if non-zero, it sets "throw exception", then acquires fatlock
and signals the assigned conditional variable then frees the
fatlock.
- if zero, it sets "interrupted" flag/bit.

Note this does not cover interrupt()ing I/O operations happening
in Classpath.  For that we'd need something like 2 JNI functions
to set/clear "interrupt by singal" flag that would be called around
blocking I/O functions that can be interrupted by sending a signal
to a thread.  This would also require that on EINTR these functions
call 3rd JNI function that would check whether "throw exception"
is set, and if yes, clear this flag, set "interrupted", throw
an exception and return a value indicating that the EINTR'ed I/O
should not continue.



------- You are receiving this mail because: -------
You are the assignee for the bug, or are watching the assignee.
You are the QA contact for the bug, or are watching the QA contact.