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 Thu, 15 Jun 2006 04:59:21 GMT
Tim Ellison wrote:
> 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.
Yes, I think this is Thread's implementation detail.

>   
>> 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).
>   
Yes.
>   
>> 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.
>   
The spec of AbstractInterruptibleChannel requires that begin()/end() 
should be used to mark the begin/end of blocking I/O operation, so the 
action clearance should be controlled by the end().
>   
>> 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).
>   
Yes, that's one of reasons why I propose this idea here, if it is 
accepted, I need to ask for the VMI modification.
>
> Regards,
> Tim
>
>   


-- 
Paulex Yang
China Software Development Lab
IBM



---------------------------------------------------------------------
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


Mime
View raw message