Paulex Yang wrote:
<snip>
> Seems Thread's implementation must be aware of what operation it is
> blocking on. So I propose the following solution:
>
> 1. Add this method to kernel class Thread (in VMI): private void
> setInterruptAction(Runnable action);
...and, reading on, you'll need to add a new field to Thread too to
remember the action? Though since Thread is in kernel that is the VM's
choice.
> 2. Thread's default value of action is null. Thread's interrupt() method
> will check the action field at first, if it is not null, execute the
> action at first, and then perform the normal interruption.
Requires updating the VMI spec to say that interrupt() must execute the
Runnable action if it has been set (to a non-null value).
> 3. If some interruptible blocking I/O operation is going to happen, then
> invoke this method to current thread like below (probably by reflection):
>
> Thread.currentThread().setInterruptAction(new Runnable(){
> public void run(){
> interrupted = true;
> AbstractInterruptibleChannel.this.close();
> }
> });
>
> 4. It is the AbstractInterruptibleChannel's responsibility to reset
> Thread's interrupt action to null after the blocking I/O operation.
So by default the action is not cleared? Sounds reasonable.
> 5. The interruption of select operation can be implemented in same way,
> all difference is another Runnable inner class, which invokes selector's
> wake-up.
>
> comments? ideas?
Sounds ok (but will need a change to the IBM VME | classpathadapter
before you can try it).
Regards,
Tim
--
Tim Ellison ([EMAIL PROTECTED])
IBM Java technology centre, UK.
---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
