Mailing-List: contact commits-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Message-ID: <30309093.1179854776540.JavaMail.jira@brutus>
Date: Tue, 22 May 2007 10:26:16 -0700 (PDT)
From: "Sergey Dmitriev (JIRA)" <jira@apache.org>
To: commits@harmony.apache.org
Subject: [jira] Commented: (HARMONY-3915) [classlib][nio]
 java.nio.channels.Selector.select(long timeout) throws SocketException on
 SIGUSR2
In-Reply-To: <4083007.1179588736423.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/HARMONY-3915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12497936 ] 

Sergey Dmitriev commented on HARMONY-3915:
------------------------------------------

Mark, thanks for the useful comments.

I've updated test patch adding couple of testcases and incorporating your comments.

As for the code patch... Here are some comments from my side with respect to this.

I agree that all this stuff with cycle and mathematics in Java code does not look brilliant.

Why in Java space? I did it knowingly - my first variant was located in native (hysock.c). Everything was just fine except:
    native code should somehow detect whether linux select() exited because of interruption or not - I didn't want to do JNI upcall from portlib's hysock.c.

And next issue is with interruption: linux select() doesn't return on thread.interrupt(). (By the way new "couple of testcases" is about interruption).

The same with pselect() - thanks for pointing this function out, this could shrink my fix (native fix) to about 3 code lines. But the same problem with interruption exists.

One could ask "did the original version work correctly with interruption?". No, it threw SocketException() on interruption and that is not correct either. But I think it is better than not exiting at all.

So the bottom line is that my code patch DOES fix the problem with throwing SocketException on SIGUSR2 but problem with interruption come into play. Probably the problem is in Thread.currentThread().isInterrupted(). Hope someone experienced in DRLVM threading can figure out what is going on.

Please refer to attached select.java code sample to play with. Hope this can be useful in future fixing.


> [classlib][nio] java.nio.channels.Selector.select(long timeout) throws SocketException on SIGUSR2
> -------------------------------------------------------------------------------------------------
>
>                 Key: HARMONY-3915
>                 URL: https://issues.apache.org/jira/browse/HARMONY-3915
>             Project: Harmony
>          Issue Type: Bug
>          Components: Classlib
>         Environment: linux
>            Reporter: Sergey Dmitriev
>         Assigned To: Mark Hindess
>         Attachments: 3915.patch, 3915_test_2.patch, select.java
>
>
> After fixing JIRA#3888 suddenly SelectorTest.test_wakeup() started to
> fail. So fixed 3888 has discovered another issue with selector.
> As it turned out java.nio.channels.Selector.select([long timeout])
> wakes up and throws SocketException when some thread dies. Actually it
> is all connected with the underlying linux function
>     int  select(int  n,  fd_set  *readfds,  fd_set  *writefds,
>                 fd_set *exceptfds, struct timeval *timeout)
> and SIGUSR2 which is used in DRLVM threading subsystem (any other
> threading event which sends SIGUSR2 can cause the problem with
> select()).
> AFAIK some time ago we had the same problem with SIGUSR2 and this
> issue has been easily resolved with SA_RESTART. Unfortunately in case
> of select() it is not applicable since SA_RESTART functionality in
> select() is "implementation-dependent". Quote:
>        int select(int nfds, fd_set *readfds, fd_set *writefds,
>                   fd_set *errorfds, struct timeval *timeout);
>        ...
>        ERRORS
>            Under the following conditions, select() fails and sets
>            errno to:
>        ...
>            [EINTR]
>                The select() function was interrupted before any of the
>                selected events occurred and before the timeout
>                interval expired. If SA_RESTART has been set for the
>                interrupting signal, it is implementation-dependent
>                whether select() restarts or returns with [EINTR].
>       
>        http://www.opengroup.org/onlinepubs/007908799/xsh/select.html
> As it turned out "SUSE LINUX Enterprise Server 9" on my box does not
> support SA_RESTART functionality. So I handled it with cycle. And
> therefore some timeout mathematics comes into play here as well.
> So I believe the code-fix and test-fix for this JIRA and code-fix for
> JIRA #3888 should be committed together since all this stuff intertwined.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.