Archie Cobbs wrote:
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
Indeed.
(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).
The AbstractInterruptibleChannel is open for Harmony user to extend,
which means, the end user should can simply extend the class and create
his own interruptible channel. Although I think this case is probably
less than 0.1% of all Java application, but it's class library, so we
never know how it is used, IMO that's one important reason of why we
stick to the compatibility with spec and RI.
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.
Great, so may I assume you agree with the VMI modification to add
Thread.setInterruptAction()?
-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]
--
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]
