Archie,
I tried to summary the current discussion so that it is easier to going
on, so please correct me if I missed something. Thanks.
The requirements are come from three class's Java spec,
1. java.lang.Thread.Interrupt(), which handles four scenarios in
different ways, including interruptible I/O and interruptible select
2.
java.nio.channels.spi.AbstractInterruptibleChannel.begin()/end(boolean),
which encapsulates the low-level machinery required to implement the
asynchronous closing and interruption of channels, so that the subclass
can get this capability by this:
boolean completed = false;
try {
begin();
completed = ...; // Perform blocking I/O operation
return ...; // Return result
} finally {
end(completed);
}
3. java.nio.channels.spi.AbstractSelector.begin()/end(boolean), which
encapsulates the low-level machinery required to implement the
interruption of selection operations, so that the subclass can get this
capability in similar way like 2.
And your suggestion is to use signal as mechanism of interrupt I/O, and
the solution might look like:
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.
At last, I agree with you about the concern on portable, to make
Harmony's class library portable, we cannot put much assumptions on VM's
implementation besides JLS/JVM spec/Java doc, so we cannot assume all
Thread implementation can be POSIX compliant(unless Java spec about
Thread is POSIX compliant), instead, I prefer a straightforward way
without these assumptions. And my proposal has no assumptions on the
Thread's implementation detail, has no impact to any I/O codes, fully
implements the requirements of 1-3 above, and the only concern is it
introduces one more contract between Thread and NIO, but it is probably
better than introducing more contract to Harmony users, and IMHO, the
impact is not so big, even all impacts are about kernel class Thread and
nothing related to VM, as below:
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.
}
Anything I missed? comments?
--
Paulex Yang
China Software Development Lab
IBM
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
