Return-Path: 
 <harmony-dev-return-12721-apmail-incubator-harmony-dev-archive=incubator.apache.org@incubator.apache.org>
Delivered-To: apmail-incubator-harmony-dev-archive@www.apache.org
Received: (qmail 9270 invoked from network); 31 Aug 2006 07:04:57 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 31 Aug 2006 07:04:57 -0000
Received: (qmail 6055 invoked by uid 500); 31 Aug 2006 07:04:53 -0000
Delivered-To: apmail-incubator-harmony-dev-archive@incubator.apache.org
Received: (qmail 6016 invoked by uid 500); 31 Aug 2006 07:04:53 -0000
Mailing-List: contact harmony-dev-help@incubator.apache.org; run by ezmlm
Precedence: bulk
List-Help: <mailto:harmony-dev-help@incubator.apache.org>
List-Unsubscribe: <mailto:harmony-dev-unsubscribe@incubator.apache.org>
List-Post: <mailto:harmony-dev@incubator.apache.org>
List-Id: <harmony-dev.incubator.apache.org>
Reply-To: harmony-dev@incubator.apache.org
Delivered-To: mailing list harmony-dev@incubator.apache.org
Received: (qmail 6005 invoked by uid 99); 31 Aug 2006 07:04:53 -0000
Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 31 Aug 2006 00:04:53 -0700
X-ASF-Spam-Status: No, hits=1.9 required=10.0
	tests=DNS_FROM_RFC_ABUSE,SPF_NEUTRAL
X-Spam-Check-By: apache.org
Received-SPF: neutral (asf.osuosl.org: 202.81.18.154 is neither permitted nor
 denied by domain of firepure@gmail.com)
Received: from [202.81.18.154] (HELO ausmtp05.au.ibm.com) (202.81.18.154)
    by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 31 Aug 2006 00:04:52 -0700
Received: from sd0208e0.au.ibm.com (d23rh904.au.ibm.com [202.81.18.202])
	by ausmtp05.au.ibm.com (8.13.6/8.13.6) with ESMTP id k7V76uMa4989018
	for <harmony-dev@incubator.apache.org>; Thu, 31 Aug 2006 17:06:56 +1000
Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.250.242])
	by sd0208e0.au.ibm.com (8.13.6/8.13.6/NCO v8.1.1) with ESMTP id
 k7V77QR4134330
	for <harmony-dev@incubator.apache.org>; Thu, 31 Aug 2006 17:07:27 +1000
Received: from d23av01.au.ibm.com (loopback [127.0.0.1])
	by d23av01.au.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id k7V742LX032156
	for <harmony-dev@incubator.apache.org>; Thu, 31 Aug 2006 17:04:02 +1000
Received: from d23m0011.cn.ibm.com (d23m0011.cn.ibm.com [9.181.32.74])
	by d23av01.au.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k7V7407n032099
	for <harmony-dev@incubator.apache.org>; Thu, 31 Aug 2006 17:04:01 +1000
Received: from [9.181.107.166] ([9.181.107.166])
          by d23m0011.cn.ibm.com (Lotus Domino Release 6.5.5HF262)
          with ESMTP id 2006083115033516-4019 ;
          Thu, 31 Aug 2006 15:03:35 +0800
Message-ID: <44F689CC.8080505@gmail.com>
Date: Thu, 31 Aug 2006 15:03:40 +0800
From: "Jimmy, Jing Lv" <firepure@gmail.com>
User-Agent: Thunderbird 1.5.0.5 (Windows/20060719)
MIME-Version: 1.0
To: harmony-dev@incubator.apache.org
Subject: Re: [classlib][luni] signalis interruptus in hysock
References: <6F10D6EB-4F24-4543-8E41-8B943F24E6DE@pobox.com>
	 <44F651D8.9060809@gmail.com>
 <f944d83d0608302323m1c129958q8cde97cc2733cffd@mail.gmail.com>
In-Reply-To: <f944d83d0608302323m1c129958q8cde97cc2733cffd@mail.gmail.com>
X-MIMETrack: Itemize by SMTP Server on D23M0011/23/M/IBM(Release 6.5.5HF262 |
 April 5, 2006) at
 31/08/2006 15:03:35,
	Serialize by Router on D23M0011/23/M/IBM(Release 6.5.5HF262 | April 5,
 2006) at
 31/08/2006 15:04:01,
	Serialize complete at 31/08/2006 15:04:01
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

Alexey Varlamov wrote:
> Guys,
> 
> Probably I missed that thread on InterruptibleChannel implementation,
> but I've just hit on the following code in
> java.nio.channels.spi.AbstractInterruptibleChannel:
> 
> static {
> try {
>     setInterruptAction = AccessController
>     .doPrivileged(new PrivilegedExceptionAction<Method>() {
>         public Method run() throws Exception {                return
> Thread.class.getDeclaredMethod("setInterruptAction",            new 
> Class[] {
> Runnable.class });
>         }
>     });
>     setInterruptAction.setAccessible(true);
> } catch (Exception e) {
>     // FIXME: be accomodate before VM actually provides
>     // setInterruptAction method
>     // throw new Error(e);
> }
> }
> 
> There are no docs on j.l.Thread.setInterruptAction()... Does this code
> snippet relate to the subject of this discussion?
> 

Hi,

     The SIGUSR2 is much more powerful than I think. If it can really 
break select operation without other harmful side-effect, I believe it 
is a good way to Interrupt Channel.
     IIRC, setInterruptAction is used if VM can not interrupt some I/O 
blocking operation, like select(), so it set a callback and ask classlib 
method to stop them(close fd, etc). But if SIGUSR2 works so well, I 
doubt it is not necessary then.
     BTW, can it break socket read/write or other blocking operation as 
well? (I'm very interested in how does it work, as common thread 
mechanism know nothing how to stop a certain I/O :) )

> -- 
> Alexey
> 
> 2006/8/31, Paulex Yang <paulex.yang@gmail.com>:
>> Geir Magnusson Jr. wrote:
>> > Time to take another run at this since I didn't get any responses on
>> > the drlvm thread.
>> >
>> > We have the problem that DRLVM uses SIGUSR2 in the thread manager (not
>> > an unreasonable thing to do, I believe) but this results in knocking
>> > threads out of select() in hysock.c (and I'm sure we'll see it in
>> > other places.)
>> >
>> > Now, I'm not sure what the right course of action is.  We have a
>> > suggested patch from Artem that suggests we just ignore when the tread
>> > is interrupted :
>> >
>> > --- modules/luni/src/main/native/port/linux/hysock.c
>> > +++ modules/luni/src/main/native/port/linux/hysock.c
>> > @@ -2570,11 +2570,16 @@ hysock_select (struct HyPortLibrary * po
>> >   I_32 rc = 0;
>> >   I_32 result = 0;
>> >
>> > -  result =
>> > +  do
>> > +  {
>> > +    result =
>> >     select (nfds, readfds == NULL ? NULL : &readfds->handle,
>> >             writefds == NULL ? NULL : &writefds->handle,
>> >             exceptfds == NULL ? NULL : &exceptfds->handle,
>> >             timeout == NULL ? NULL : &timeout->time);
>> > +  }
>> > +  while (result == -1 && errno == EINTR);
>> > +
>> >   if (result == -1)
>> >     {
>> >       rc = errno;
>> IIRC, months ago similar approach was discussed in another thread for
>> j.nio.channels.InterruptibleChannel implementation, but IMHO it can be a
>> workaround but is not acceptable as a solution, because
>> InterruptibleChannel is extensible by user application, i.e., user can
>> implement their own interruptible blocking I/O easily without
>> considering too much on thread sync issues, it's not reasonable to ask
>> user writing codes within a loop like this.
>> >
>> >
>> > this works, but I'm bothered by the fact that we're just blindly
>> > ignoring signals like this.  I also think that I need to go and do
>> > this everywhere we have a non-restarted interruptable blocking system
>> > call.
>> >
>> > Now, I'd like to get this fixed today, as it's high time for another
>> > snapshot of the JRE and HDK, but w/o it, Tomcat runs for 2 seconds at
>> > best :)
>> >
>> > So - does anyone have any other bright ideas?  Why don't we see this
>> > with J9?    Would it be better to do a per-thread signal mask after
>> > asking the thread manager what signal it's using du jour?  (Andrey
>> > noted that Sun allows one to change the signals used, apparently to
>> > prevent collision w/ user code vi JNI, I guess...)
>> >
>> > geir
>> >
>> >
>> >
>> >
>> > ---------------------------------------------------------------------
>> > 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
>>
>>
> 
> ---------------------------------------------------------------------
> 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
> 
> 


-- 

Best Regards!

Jimmy, Jing Lv
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