Re: Thread.interrupt() etc

Re: Thread.interrupt() etc

[Mojo Jojo]

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.

Re: Thread.interrupt() etc

[Mojo Jojo]

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.

RE: Thread.interrupt() etc

[Miles Sabin]

Mojo Jojo wrote,
> - Does anyone care about async cancelation yet?  Analogy:  
> hardware interrupt, between any two instructions vs only at 
> certain subroutine calls.

Yes: don't do it. Java doesn't support async cancellation ...
Thread.stop() isn't just deprecated, it's no longer implemented
in any of Sun's recent JVMs.

> There are codegen complications.

You betcha ...

Cheers,


Miles

-- 
Miles Sabin                       Cromwell Media
Internet Systems Architect        5/6 Glenthorne Mews
+44 (0)20 8817 4030               London, W6 0LJ, England
msabin@cromwellmedia.com          http://www.cromwellmedia.com/

RE: Thread.interrupt() etc

[Miles Sabin]

Mojo Jojo wrote,
> - Does anyone care about async cancelation yet?  Analogy:  
> hardware interrupt, between any two instructions vs only at 
> certain subroutine calls.

Yes: don't do it. Java doesn't support async cancellation ...
Thread.stop() isn't just deprecated, it's no longer implemented
in any of Sun's recent JVMs.

> There are codegen complications.

You betcha ...

Cheers,


Miles

-- 
Miles Sabin                       Cromwell Media
Internet Systems Architect        5/6 Glenthorne Mews
+44 (0)20 8817 4030               London, W6 0LJ, England
msabin@cromwellmedia.com          http://www.cromwellmedia.com/