Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: harmony-dev@incubator.apache.org
Received-SPF: pass (asf.osuosl.org: domain of zhanghuangzhu@gmail.com
 designates 66.249.82.195 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=WEc1BxWxQW+9y7gA34Se+Kv9GDf7Hd07FjLOXajzhx3jtgTMY4d7zE3rne7blVaxd17qlj7M35lfzVmCR8n41zlHg9cPxTITS+vBeh71wJ2inXzYv3vWCyxMzU/ELj1WQ32SqhuleV1ZG0fCawWWBO5WtAORgAuJ3nEE0tOnSFE=
Message-ID: <4d0b24970606191955t20a6e3bds754b3294266b3f7b@mail.gmail.com>
Date: Tue, 20 Jun 2006 10:55:27 +0800
From: "Andrew Zhang" <zhanghuangzhu@gmail.com>
To: harmony-dev@incubator.apache.org
Subject: Re: [Fwd: [classlib][NIO|VMI]Interruptible channel implementation -
 how to interact with Thread?]
In-Reply-To: <44974BF2.4060502@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_100373_20404055.1150772127713"
References: <448FBC7B.1040808@gmail.com> <44901053.3040109@dellroad.org>
	 <4490C2C4.10502@gmail.com> <4490EF22.1050501@gmail.com>
	 <44918085.20205@dellroad.org> <44921930.1070702@gmail.com>
	 <4492FE9A.9060305@dellroad.org> <44961FF8.1060102@gmail.com>
	 <4496A9A0.3000809@dellroad.org> <44974BF2.4060502@gmail.com>

------=_Part_100373_20404055.1150772127713
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

------=_Part_100373_20404055.1150772127713--