This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: [PATCH] [POSIX]: natSelectorImplPosix.cc Fixes
- From: Mohan Embar <gnustuff at thisiscool dot com>
- To: Michael Koch <konqueror at gmx dot de>
- Cc: java-patches at gcc dot gnu dot org
- Date: Thu, 11 Dec 2003 06:57:11 -0600
- Subject: Re: [PATCH] [POSIX]: natSelectorImplPosix.cc Fixes
- Reply-to: gnustuff at thisiscool dot com
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.
>> + {
>> + // 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....
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.
-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/