Re: Problems implementing _Jv_select() on Win32

[Michael Koch <konqueror at gmx dot de>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Am Sonntag, 13. April 2003 15:42 schrieb Mohan Embar:
> 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.

The real problem is that this stuff is not really implemented yet 
because I want to find the correct solution (tm) first.

Michael
- -- 
Homepage: http://www.worldforge.org/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (GNU/Linux)

iD8DBQE+p9bzWSOgCCdjSDsRAjlfAJwOvkakMVje3RN/hq+/i2mhvSE7AgCeJYjD
bK5oK8vEJETAybJmfE+FLjo=
=wl0l
-----END PGP SIGNATURE-----