Problems implementing _Jv_select() on Win32

[Mohan Embar <gnustuff at thisiscool dot com>]

Hi People,

> > Applying Michael's changes (with a subsequent iteration on the
> > Win32 side to fix broken things) would be the most desirable, but
> > Michael said he wasn't able to commit to 3.3.
> > Doing a dummy _Jv_select would leave natSelectorImpl.cc untouched.
>
>Sounds good.  Can you please submit a patch that does this for 3.3?

While trying to do the above, I thought I would take a stab at doing
a real _Jv_select() since Win32 also has select() with the same
signature. I lifted some of Michael's code from posix.cc and was able
to do this, but am running into the following problem while trying
to test this using the small program I got from here:

http://developer.java.sun.com/developer/technicalArticles/releases/nio/

...which I've put at the end of the message.

I'll attempt to explain here why I think things are going wrong and
then ask:

- if this analysis is correct
- if so, what we should do

Here is what I think is going wrong:

The call
  
ServerSocketChannel.open();

eventually trickles down to:

ServerSocketChannelImpl.ServerSocketChannelImpl(SelectorProvider provider)

which creates a socket here:

fd1 = SocketChannelImpl.SocketCreate();

but also calls

sock_object = new ServerSocket();

which creates yet another socket (file descriptor) fd2

via impl.create()

Next, the call to:

channel.socket().bind(isa);

actually does the underlying bind and listen() for fd2, but
it is fd1 which is actually passed to _Jv_select(). I'm suspecting
that this works on Linux because I think we're binding both
sockets to the same port, but Win32 is not happy with this.
I suspect the problem will be resolved if I pass fd2 to _Jv_select()
instead of fd1. However, fd2 might not that be easy to get at.

Before I continue with this any further, I need to know:

- Is this considered show-stopping enough to fix for 3.3?
- If so, is my analysis correct?

I'm not looking for too much handholding here. If you give me
the word to keep digging into this and submit a patch (which
would take me some time and most definitely touch non-MingW-specific
code), then I'll keep digging. However, if you want to pull the
plug on this effort in order to get GCC 3.3 out the door right
away, I'll focus my energy on the more mundane testing I said
I'd do.

-- Mohan
http://www.thisiscool.com/
http://www.animalsong.org/

Here is the sample program:

------------------------------8<----------------------------------
import java.io.*;
import java.net.*;
import java.nio.*;
import java.nio.channels.*;
import java.util.*;

public class Server {
   private static int port = 9999;
   public static void main(String args[])
     throws Exception {
     Selector selector = Selector.open();

     ServerSocketChannel channel =
       ServerSocketChannel.open();
     channel.configureBlocking(false);
     InetSocketAddress isa = new InetSocketAddress(port);
     channel.socket().bind(isa);

     // Register interest in when connection
     channel.register(selector, SelectionKey.OP_ACCEPT);

     // Wait for something of interest to happen
     while (selector.select() > 0) {
       // Get set of ready objects
       Set readyKeys = selector.selectedKeys();
       Iterator readyItor = readyKeys.iterator();

       // Walk through set
       while (readyItor.hasNext()) {

         // Get key from set
         SelectionKey key =
           (SelectionKey)readyItor.next();

         // Remove current entry
         readyItor.remove();

         if (key.isAcceptable()) {
           // Get channel
           ServerSocketChannel keyChannel =
             (ServerSocketChannel)key.channel();

           // Get server socket
           ServerSocket serverSocket = keyChannel.socket();

           // Accept request
           Socket socket = serverSocket.accept();

           // Return canned message
           PrintWriter out = new PrintWriter
             (socket.getOutputStream(), true);
           out.println("Hello, NIO");
           out.close();
         } else {
           System.err.println("Ooops");
         }

       }
     }
     // Never ends
   }
}
------------------------------8<----------------------------------


4/11/2003 11:52:12 AM, Andrew Haley <aph at redhat dot com> wrote:

>Mohan Embar writes:
> > Andrew,
> > 
> > >Please check out and download the 3.3 branch and try it on Windows.
> > >
> > >If there's anything still broken we need to know.
> > 
> > I can tell you right away which things are broken that I know about.
> > Although I believe this list is complete, I will do another get and build
> > this weekend.
>
>Thanks.  I checked in your strict case patch.  Of course I haven't
>tested it, so please make sure you do that.
>
> > In general, I list extra unofficial or uncommitted patches on my download
> > page:
> > 
> > http://www.thisiscool.com/gcc33_mingw.htm
> > 
> > ...which provide a vague idea of what I think is missing from the sources.
> > 
> > Here is a more detailed list:
> > 
> > BUILD-BREAKING PROBLEMS
> > 
> > 1. Patch: Suppress MingW Build-Busting Net Code
> > http://gcc.gnu.org/ml/java-patches/2003-q1/msg00670.html
> > 
> > Remarks: Michael Koch has split off the Win32 and Posix NET
> > code at the trunk, but not in 3.3. If his changes are deemed too
> > radical for 3.3, the above patch should be a quick an ugly fix
> > which suppresses the problems for 3.3. Michael had originally commented
> > that for gnu/java/nio/natSelectorImpl.cc, I should really
> > define a do-nothing _Jv_select for Win32.. So there are three
> > possibilities (listed in descending order of correctness)
> > 
> > - apply Michael's trunk changes to 3.3
> > - define a dummy _Jv_select as per Michael
> > - just use my #ifdef in the above patch
>
>Tom, do you care which one of these happens?
>
> > Applying Michael's changes (with a subsequent iteration on the
> > Win32 side to fix broken things) would be the most desirable, but
> > Michael said he wasn't able to commit to 3.3.
> > Doing a dummy _Jv_select would leave natSelectorImpl.cc untouched.
>
>Sounds good.  Can you please submit a patch that does this for 3.3?
>
> > 2. Patch: natSocketChannelImpl.cc use elements + explicit cast
> > http://gcc.gnu.org/ml/java-patches/2003-q1/msg00672.html
> > 
> > Michael found this to be correct and committed it to the trunk,
> > but not 3.3.
>
>Michael, is there a good reason not to apply this to 3.3?
>
> > IRRITATING (but not build-breaking) PROBLEMS
> > 
> > 3. Patch for Preview: Escape DllMain in boehm-gc (Take 2)
> > http://gcc.gnu.org/ml/java-patches/2003-q1/msg00669.html
> > 
> > Not having this prevents creating DLLs on Windows which
> > use the gcj runtime. Hans recently said that although the remedy
> > wasn't ideal, he was okay with this being checked in:
> > 
> > http://gcc.gnu.org/ml/java/2003-04/msg00068.html
>
>Tom?  What do you think?
>
> > 4. Patch: Make "os.arch" consistent with Sun's JDK on Win32
> > http://gcc.gnu.org/ml/java-patches/2003-q1/msg00445.html
> > 
> > On MingW, System.getProperty("os.arch") returns i586 instead
> > if x86 which, though seemingly innocuous, causes some things
> > (like SWT) to behave incorrectly. Tom didn't put this in because
> > he said this stuff belongs more properly in config.host and not here
> > (see the followup).
>
>Okay, but let's do something simple like this for 3.3.
>
> > It looks like my case-sensitivity and Erik's 0-concatenation fixes are
> > going in, so I can stop hand-adding these and remove them from my
> > website.
>
>Yes.
>
>Andrew.
>