Re: [PATCH] [POSIX]: natSelectorImplPosix.cc Fixes

[Michael Koch <konqueror at gmx dot de>]

On Thu, Dec 11, 2003 at 06:57:11AM -0600, Mohan Embar wrote:
> Hi Michael,
> 
> >> I know you said you would look into this, but my fingers started
> >> itching, and I couldn't help myself....
> >
> >Damn, too much work for not enought time ...
> 
> The configury stuff was pretty cool....
> 
> >>    // Actually do the select
> >> -  result = _Jv_select (max_fd + 1, &read_fds, &write_fds, &except_fds, time_data);
> >> +  try
> >> +    {
> >> +      result = _Jv_select (max_fd + 1, &read_fds, &write_fds,
> >> +                           &except_fds, time_data);
> >> +    }
> >> +  catch (::java::io::InterruptedIOException *e)
> >
> >Can't we do this in the Java code ? (in SelectorImpl.java)
> 
> I don't think so. That _Jv_select() throws an InterruptedIOException
> when the thread is interrupted is implementation-dependent (posix.cc).
> Recall that getting the mainline to work was my prerequisite to
> writing an interruptible implSelect() in natSelectorImplWin32.cc.
> I plan on removing _Jv_select() completely in MinGW.

I though tabout removing it for Posix too ...

> >> +    {
> >> +      // The behavior of JRE 1.4.1 is that no exception is thrown
> >> +      // when the thread is interrupted, but the thread's interrupt
> >> +      // status is set. Clear all of our select sets and return 0,
> >> +      // indicating that nothing was selected.
> >> +      ::java::lang::Thread::currentThread ()->interrupt ();
> >> +       helper_reset (read);
> >> +       helper_reset (write);
> >> +       helper_reset (except);
> >
> >Do we really need this ? The helper arrays are supposed to be recreated
> >before each selectImpl() call.
> 
> I think we do need this because the read, write and except parameters
> to implSelect() are in/out parameters. I believe we need to clear
> these before returning from implSelect() because SelectorImpl.java
> uses them on return to see which file descriptors are actually selected.
> Since we are no longer suppressing the InterruptedIOException, the
> return to SelectorImpl.java after thread interruption is a normal return....

You are right and after thinking more about I can explain some weird
experiences I had with the old code.

> Let me know if you want me to commit this after I've made the other
> changes you mentioned (like for alphabetical order) or whether
> some of my above assumptions are incorrect.

I get a hang in one of the testcases of NetTest but I get much further
then before. Please commit adn let use search for more bugs after
commit.


Michael