Paulex Yang wrote:
I. B send interrupt signal to A, and A responses by doing right thing
II. For select(), using signal to wake it up, and
AbstractSelector.begin()/end() actually don't need to do much things
III. For blocking I/O, begin()/end() should set/reset some
per-thread(IIUC, ThreadLocal) flags, when the thread is wakeup from I/O,
the I/O classlib native codes checks the flags, if it is set, then the
I/O is "interruptible" and everything is OK so just going on, but if
not, which means the I/O is actually not "interruptible", so that the
I/O classlib native codes should invoke the I/O system call again to
blocking again.
But the issues are:
a. for I, and I'm not sure how to wake up windows thread blocking on
I/O, except close the file descriptor
b. for II, I have no idea how to wake up a Windows thread blocking on
select, except secret wake up fd, or loop in Java codes with
select(timeout)
c. for III, this solution impacts much to most I/O codes, first, it is
hard for begin()/end() to encapsulate the machinery, every blocking I/O
system call invocation must take care of the interruptible flag. And
more significant, it is difficult to extend the
AbstractInterruptibleChannel like spec requires, because at first the
developer should care about the flags and make his I/O codes loop, and
then he must know about the flags, because begin()/end() is final, so
that it is impossible except we introduce more contract to Harmony users
besides Java spec.
For (a) and (b), the POSIX pthread_kill() function would work... but
of course that requires POSIX compatibility (this doesn't seem like
a big requirement to me but then again I don't program on Windows).
But I don't understand (c): every blocking I/O call is implemented
in classlib native code, so the Java developer is not involved (the
looping, checking of flags, etc. would be done in the native I/O code).
To me it boils down to whether we can assume POSIX siganls are
available. If not, then I agree we need the "interrupt actions".
1. add a setInterruptAction(Runnable action), its implementation is
straightforward
2. Thread.interrupt() is supposed to be like this:
public void interrupt(){
if(interruptAction != null){
interruptAction.run();
}
interruptImpl();//do what it supposed to do before interruptible NIO
world.
}
OK, this is nice and simple.. installing an interrupt action is a clean
and Java-centric way to make the handling of interrupts explicit. It may
be technically unnecessary (if POSIX signals were available) but has
the advantage of being less tied to the O/S and VM internals.
-Archie
__________________________________________________________________________
Archie Cobbs * CTO, Awarix * http://www.awarix.com
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
