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 Mon, 19 Jun 2006 13:41:52 GMT
Paulex Yang wrote:
> I. B send interrupt signal to A, and A responses by doing right thing
> II. For select(), using signal to wake it up, and 
> AbstractSelector.begin()/end() actually don't need to do much things
> III. For blocking I/O, begin()/end() should set/reset some 
> per-thread(IIUC, ThreadLocal) flags, when the thread is wakeup from I/O, 
> the I/O classlib native codes checks the flags, if it is set, then the 
> I/O is "interruptible" and everything is OK so just going on, but if 
> not, which means the I/O is actually not "interruptible", so that the 
> I/O classlib native codes should invoke the I/O system call again to 
> blocking again.
> But the issues are:
> a. for I, and I'm not sure how to wake up windows thread blocking on 
> I/O, except close the file descriptor
> b. for II, I have no idea how to wake up a Windows thread blocking on 
> select, except secret wake up fd, or loop in Java codes with 
> select(timeout)
> c. for III, this solution impacts much to most I/O codes, first, it is 
> hard for begin()/end() to encapsulate the machinery, every blocking I/O 
> system call invocation must take care of the interruptible flag. And 
> more significant, it is difficult to extend the 
> AbstractInterruptibleChannel like spec requires, because at first the 
> developer should care about the flags and make his I/O codes loop, and 
> then he must know about the flags, because begin()/end() is final, so 
> that it is impossible except we introduce more contract to Harmony users 
> besides Java spec.

For (a) and (b), the POSIX pthread_kill() function would work... but
of course that requires POSIX compatibility (this doesn't seem like
a big requirement to me but then again I don't program on Windows).

But I don't understand (c): every blocking I/O call is implemented
in classlib native code, so the Java developer is not involved (the
looping, checking of flags, etc. would be done in the native I/O code).

To me it boils down to whether we can assume POSIX siganls are
available. If not, then I agree we need the "interrupt actions".

> 1. add a setInterruptAction(Runnable action), its implementation is 
> straightforward
> 2. Thread.interrupt() is supposed to be like this:
> public void interrupt(){
>    if(interruptAction != null){
>       interruptAction.run();
>    }
>    interruptImpl();//do what it supposed to do before interruptible NIO 
> world.
> }

OK, this is nice and simple.. installing an interrupt action is a clean
and Java-centric way to make the handling of interrupts explicit. It may
be technically unnecessary (if POSIX signals were available) but has
the advantage of being less tied to the O/S and VM internals.


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

View raw message