On Tue, Jul 22, 2003 at 10:05:49AM -0700 it came to pass that Damien Neil wrote: > Some Java programs, as you say, build a > single-threaded, non-blocking, event-dispatched IO mechanism on top > of this. Java does not, however, have any support for interrupts; > it is not possible to do AIO in Java.
You are (of course :-) correct. Java has no support for "true" AIO since there are (fortunately) no facilities for interrupting a thread to handle an async signal and then have that thread resume its work. That's why this is widely simulated as (you and I) described: by having a thread dispatch a blocking I/O call and sending an event to interested parties (registered event listeners) as the I/O completes. There are interesting synchronisation and threading issues involved in this because the thread that executes the callback routine is (almost always) a different one than the one that registered its interest in the event. As a veteran writer of MT-code and teacher of classes on that topic it is my personal opinion that we would be much better off with a good/clean system for non-blocking I/O and handling async (Unix) signals than with an interface that exposes the full "power" of async signals for everyone to use as they see fit. In my classes (e.g. Programming multi-threaded C with Posix Threads) I try to steer my students towards using one of the available patterns for handling signals because designing and building a solid signal handler that works in all circumstances is beyond most programmers (including me). ++Jos.nl -- ek is so lug jy vlieg deur my sonder jou is ek sonder patroon "Breyten Breytenbach"
