On 6/17/06, Archie Cobbs <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[1] http://www.microsoft.com/technet/interopmigration/unix/sfu/pthreads0.mspx#EYFAC -- Andrew Zhang China Software Development Lab, IBM
