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 05:24:50 GMT
Jimmy, Jing Lv wrote:
> Archie Cobbs wrote:
>> Paulex Yang wrote:
>>> Seems Thread's implementation must be aware of what operation it is 
>>> blocking on. So I propose the following solution:
>>
>> I don't think the VM or java.lang.Thread needs to be involved.
>> First of all, the code performing the blocking operation knows
>> what kind of operation it is, so when it wakes up abnormally it
>> can take the appropriate action. This code doesn't necessarily
>> reside in java.lang.Thread.
>>
>> In Classpath the java.nio stuff is all implemented in native
>> libraries without the VM or java.lang.Thread being specially
>> "aware" of anything. However, classlib's design may be different
>> enough to need it (I haven't studied it as much as you guys).
>>
>> E.g., the java.nio native code does invoke Thread.interrupt() and
>> Thread.interrupted(), but these are normal, API-specified methods.
>>
>> Might be worth taking a look for some design ideas.
>>
>
> Thanks Archie, it sounds interesting :).
> As I study few about Classpath, I still have a question here. As we 
> know, there are three states of "blocking" on a thread. One is wait(), 
> sleep() and so forth, thread class handle them itself, it is easy to 
> interrupt; and one is blocking on I/O, invoke Thread.interrupt() may 
> be not enough as it is blocked on a system call, e.g., call read on 
> socket may not return until it receive something or it is closed. In 
> this way, the Thread.interrupt should know how to close the socket to 
> perform the real interruption. The question is: how can the thread 
> know if it is blocked on wait() or I/O operation currently? I think 
> this is the reason why Paulex require Thread to be involved. So I'm 
> very interested in what does Classpath do here to stop I/O operation 
> without get involved?
Actually Thread.interrupt() is required to handle four different scenario:
1. wait(), join(), etc, throw InterruptException
2. blocking I/O, close the channel, and throw ClosedByInterruptException
3. blocking select, wake up the selector
4. none of above, just set the thread's interrupt status

So if we don't involve Thread and want to implment scenario 2 and 3, we 
may find the situation is:
a. If Thread cannot judge scenario 2/3, so it may think they are both 
scenario 4, so Thread.interrupt() just set the interrupt status and do 
nothing else, the I/O operation is still blocking there, we cannot get 
it actually interrupted.
b. If Thread can find the thread is blocking somewhere, and it considers 
all blocking as scenario 1, so the InterruptException is thrown, but 
considering scenario 3, Selector.select() should be waked up without 
exception, while our selector only has the end() executed in finally 
block like below, how does end() catch the thrown InterruptException and 
handle it silently?

try {
     begin();
     // Perform blocking I/O operation here
     ...
 } finally {
     end();
 }
c. If Thread can magically find the thread is blocking on I/O or select, 
it may need to set the interrupt status, and make the blocked Java 
method return with some error, so that the end() can check them. 
Further, the Thread needs to know if this blocking I/O is 
"interruptible" in Java, for example, the ServerSocket.accept() and 
ServerSocketChannel.accept() probably uses same system call, but Thread 
should know ServerSocket cannot be interrupted while ServerSocketChannel 
can...I have no any idea how Thread can do this without interaction with 
NIO channels.

So, Archie, I'm very interested in how Classpath handle this problem. 
Would you please help to give more details for it (if no legal concern)?
>
> Here is the spec about Thread.interrupt():
>
> "
> ...
> If this thread is blocked in an invocation of the wait(), wait(long), 
> or wait(long, int) methods of the Object  class, or of the join(), 
> join(long), join(long, int), sleep(long), or sleep(long, int), methods 
> of this class, then its interrupt status will be cleared and it will 
> receive an InterruptedException.
> If this thread is blocked in an I/O operation upon an interruptible 
> channel then the channel will be closed, the thread's interrupt status 
> will be set, and the thread will receive a ClosedByInterruptException.
> ...
> "
>
>> -Archie
>>
>> __________________________________________________________________________ 
>>
>> Archie Cobbs      *        CTO, Awarix        *      
>> http://www.awarix.com
>>
>> ---------------------------------------------------------------------
>> 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
>>
>>
>
>


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