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 Tue, 20 Jun 2006 02:55:27 GMT
Great, Paulex!

I can't wait to see begin/end implementation, since there're lots of FIXME
in network related files are depending on these two methods.  Go, go ,
thanks!

On 6/20/06, Paulex Yang <paulex.yang@gmail.com> wrote:
>
> Archie Cobbs wrote:
> > 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
> Indeed.
> > (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).
> The AbstractInterruptibleChannel is open for Harmony user to extend,
> which means, the end user should can simply extend the class and create
> his own interruptible channel. Although I think this case is probably
> less than 0.1% of all Java application, but it's class library, so we
> never know how it is used, IMO that's one important reason of why we
> stick to the compatibility with spec and RI.
> >
> > 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.
> Great, so may I assume you agree with the VMI modification to add
> Thread.setInterruptAction()?
> >
> > -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
>
>


-- 
Andrew Zhang
China Software Development Lab, IBM

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