Thread.interrupt() etc

Thu Mar 16 09:57:00 GMT 2000

I agree with the direction Hans sketched: some common mechanism
seems like it should be able to handle InterruptedException as well as
pthread_cancel() and such. I'm curious how much of that mechanism
exists now, but don't have all the code in hand to figure it out!
- When unwinding a thread stack (for a clean or exceptional exit,
 not a "kill") pthreads has a stack of "cleanup" functions to invoke.
 Ideally those should be appropriately interleaved with destruction
 of C++ stack-resident objects, releasing monitors, executing Java
 "finally" clauses, and so on -- each stack frame (and maybe lesser
 scopes too) may need specialized cleanup.
 Are all those aspects of unwinding now integrated? (I'd guess
 that the pthreads cleanup functions aren't, but would be happy
 to be wrong!)
- As of Redhat 6.0, "man pthread_cancel" said (BUGS) that many
 C library functions (syscalls, printf, etc) aren't cancelation points,
 although POSIX says they must be. I don't recall Solaris listing
 such bugs, but someone else may know better.
 This should affect coding of all LIBGCJ methods calling those library
 functions. In LinuxThreads, pthread_cancel() sends a signal, so the
 natural implementation of Thread.interrupt() could cause lots of
 unexpected EINTR failures, from deep inside the system libraries.
 I'd expect that more mature pthreads implementations, e.g. the one
 on Solaris, don't have many such issues.
- Does anyone care about async cancelation yet? Analogy: hardware
 interrupt, between any two instructions vs only at certain subroutine
 calls. There are codegen complications.
If all is done correctly, I think it'll be straightforward for CNI methods
to just call pthread_testcancel(), which would trigger unwinding, maybe
by creating and throwing an InterruptedException. I don't think any C
or C++ code would normally see such exception objects.
Yes, I do agree that it'd be better not to accept the alleged Win32 flaws
except when using Win32 threading ... and even there, likely there's a
workaround available.