harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paulex Yang <paulex.y...@gmail.com>
Subject Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation - how to interact with Thread?]
Date Mon, 19 Jun 2006 03:54:32 GMT

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
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 {
      completed = ...;    // Perform blocking I/O operation
      return ...;         // Return result
    } finally {
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 
2. Thread.interrupt() is supposed to be like this:
public void interrupt(){
    if(interruptAction != null){
    interruptImpl();//do what it supposed to do before interruptible NIO 

Anything I missed? comments?

Paulex Yang
China Software Development Lab

Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

View raw message