Back in the day, when Sun OEMed Lucid's Common Lisp, I worked on our programming environment product, and spent many happy hours fiddling with the Lucid, CLOS, and Emacs internals.
The Lisp system supported responsive user-generated interrupts: A Control-C (and Control-G in Emacs IIRC) was able to cancel a computation with little or no latency. There was a form WITH- INTERRUPTIONS-INHIBITED which would guard a computation's critical sections, and of course UNWIND-PROTECT (in Java, try/finally) to perform required cleanups. Yet (and here's the point of the story) I always had the feeling that I was taking my life in my hands when I would issue a hard interrupt. Maybe as much as 1% of the time something would go badly wrong and the system would enter a disallowed state, and I'd have to restart the whole programming environment. Low-latency timeout interrupts will have the same risks. That's why Java deprecated Thread.stop long ago. (Josh Bloch insisted over my objections. Josh, you were right. That feature comes with a never- ending tail of low-frequency bugs.) Although the JVM has a nice high- level bytecode model, there is plenty of Java code out there that will put the system into disallowed states if interrupted between any two bytecodes, or at any loop back-edge, or at any other implicit poll point you care to define. Note that the stakes are higher with Java than with Lisp, since Java supports true MP concurrency, so there are many more ways to tie the global state in knots. Java also advertises security guarantees. Do you really want black hats torturing Java programs with timeout interrupts, looking for exploitable states? (Rhetorical answer: I didn't think so.) Bottom line: I think Java is stuck with explicit polling for interrupts. Best, -- John --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
