harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Zhang" <zhanghuang...@gmail.com>
Subject Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation - how to interact with Thread?]
Date Sat, 17 Jun 2006 08:27:08 GMT
On 6/17/06, Archie Cobbs <archie@dellroad.org> wrote:
>
> 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??)


So it's called POSIX, not POSM$ :)

But I found following documents from Microsoft website [1]

"Starting with the Services for UNIX 3.5 release, Interix includes support
for POSIX threads and POSIX internationalization.  Many new APIs are
available in this release and several utilities have been enhanced to make
use of this new functionality.  For instance, the utility /bin/localedef can
be used to create customized locales for use in Europe and Asia.

The introduction of thread support is very exciting because it opens the way
for a new class of utilities to be migrated from existing UNIX systems to
Interix and Windows."

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


Yes. If I understand correctly, what you mean is the interrupted thread will
executes end method in finally block, while end will do some clean work as
spec discribes. I think it works when the thread is blocked on select and
InterruptibleChannel. But  consider following case:

if thread A is block on ServerSocket.accept(), then A is interrupted by
another thread. What should be the result?
Spec says "If none of the previous conditions hold then this thread's
interrupt status will be set. "
Only interrupt status should be set and thread A should keep blocking!  RI
also behaves in this way.
Therefore, I'm not sure whether signal communicatoin works for this
scenario.
If a signal is sent to one thread, then the target is really "killed".
But interrupt concept in java.lang.Thread is not the same as that in native
OS. For java, the interrupted thread ends its lifecycle in some situations
while it keeps the same as if no interrupt happens except that the interrupt
status is set  in other situations.
Comments? Please correct me if I'm missing something. Thanks!


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
>
>
[1]
http://www.microsoft.com/technet/interopmigration/unix/sfu/pthreads0.mspx#EYFAC

-- 
Andrew Zhang
China Software Development Lab, IBM

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message