Archie Cobbs wrote:
Paulex Yang wrote:
I'm still curious what mechanism will be used to wakeup blocked threads
though.
And when Thread.interrupt() executes the interruptAction and closes
the channel, generally the blocking I/O operation will return with an
error code, and if Harmony user implements a subclass of
AbstractInterruptibleChannel, he is required by spec to implement
implCloseChannel(which is invoked by close()) in similar way, in both
cases, the thread is waken up as by product.
The blocking select is waken up in similar way by invoke wakeup() in
interruptAction.
Thanks.. for the other cases.. e.g. a thread blocked in Object.wait(),
Thread.join(), or Thread.sleep(), I guess they will require an
"interrupt action" which invokes a native method (equivalent to
the current situation), right? I.e., these cases would be handled
entirely by the VM.
Actually I propose the default value of "interrupt action" is null,
which means the VM will do what it suppose to do for the general
cases(wait(), join(), etc) as before, so the interrupt() might looks like:
public void interrupt(){
if(action != null){
action.run();
}
//call native method to do what it supposed to do
interruptImpl();
}
And as the part of the proposal, the end() of AbstractSelector and
AbstractInterruptibleChannel will reset the thread's interrupt action to
null, which marks the blocking I/O/select operation ends.
-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]
