harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Archie Cobbs <arc...@dellroad.org>
Subject Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation - how to interact with Thread?]
Date Fri, 16 Jun 2006 18:55:22 GMT
Paulex Yang wrote:
>> In Classpath, if select(2) returns EINTR, the select just returns 
>> normally
>> (with nothing selected) and then the code checks Thread.interrupted().
>> If set, it closes and throws the exception as necessary.
> Yes I noticed that select(2) on Linux has this good feature, but I 
> cannot find similar way on Windows:(.

Let's ask a simpler question: on Windows, if a thread is blocked trying
to read from a file (or socket, or whatever), what is the mechanism by
which another thread can wake it up? Is there some substitute for
signals? If not, we'll have to use a secret "wakeup" file descriptor.

>> Also, on UNIX at least, one thread may close a file descriptor that
>> another thread is waiting on and the second thread will immediately
>> wake up with an error. So that case is easy to handle.
> Yes, that's what I tried to do in the InterruptAction which is given to 
> Thread.setInterruptAction(). The problem here is not *how* to close the 
> file descriptor, but is if thread B want to interrupt thread A, the B 
> don't know *if* there are any file descriptor to be closed for A or 
> *which* file descriptor to close.

I was not talking about the interrupt case, but about the case where one
thread closes a file descriptor that another is waiting on (no interrupt
involved here). On UNIX, "just do it" and it works (i.e., the descriptor is
closed and the waiting thread awakens).

On the other hand, if an interrupt requires the file descriptor to be closed,
isn't that something the target thread can figure out? Then the target thread,
not the interrupting thread, would close the file descriptor after it wakes up.

To handle interrupt(), we need to pick the mechanism first, then figure
out the framework around it. If indeed the mechanism is a secret "wakeup"
file descriptor, then you're right - thread B needs to know which file
descriptor to write to. But if the mechanism is signals, then thread B
doesn't need to know what thread A is doing. For B to interrupt A, B just
sets thread A's inerrupted flag and sends a signal - no matter what A
is doing - and A responds by doing the right thing:

- If A is not blocked, A ignores the signal
- If A is in Thread.wait(), etc. it throws InterruptedException
- If A is reading from NIO, it does whatever else it's supposed to do

So: using signals makes the support infrastructure simpler, but is
less portable (really? I don't know from Windows - does Windows
not have pthread_kill(), a standard POSIX function??)

Basically with signals, all you do is get the target thread's attention..
then the target thread figures out what to do about it (if anything).

But why would this still require storing some information in the target
thread's Thread object (in the case of using signals)?

Sorry if I'm being dense here.

With the secret wakeup file descriptor, yes you'd need to have that
available in the target thread's Thread object so the sending thread
would know what to write to.

> The other problem is we may not have too many freedom to design the 
> interruption and Async close implementation, because Java spec requires 
> the related operation are encapsulated in AbstractInterruptibleChannel's 
> begin()/end() method, which mark the start/end of some interruptible I/O 
> operation, so that its subclass can get the capability easily by invoke 
> the two methods following spec. And AbstractInterruptibleChannel is 
> extensible to classlib users.

Seems like begin() and end() can just set a per-thread flag. The appropriate
blocking native methods would check this flag when woken up.

-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


Mime
View raw message