Re: [classlib][luni] signalis interruptus in hysock

[Paulex Yang <pa...@gmail.com>]

This is a VMI extension introduced by HARMONY-635, and this modification 
was discussed before in a very long thread[1]

But it's weird that, at revision r431077, it is removed, anyone knows 
why:-(.

[1] 
http://mail-archives.apache.org/mod_mbox/incubator-harmony-dev/200606.mbox/%3c448FBC7B.1040808@gmail.com%3e

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?
>
> -- 
> Alexey
>
> 2006/8/31, Paulex Yang <pa...@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
>
>


-- 
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