I will take a look this weekend. Anything which gets us closer is
a great thing. When I examined sockets last, it seemed there would need to
be quite a few caveats since Java sockets are a little more abstracted than
all other socket libraries (hence the mismatch).
The biggest pain in theory is kernel#select, but I believe for
most things only the read descriptors are actually ever used. If so
we can implement a Kernel#select wchich works with read (I have a version
in a tree somewhere). The real solution is to convert the IOHandlers
to be based on nio.
-Tom
On Thu, 27 Apr 2006, Evan Buswell defenestrated me:
> I'm trying to get WEBrick::GenericServer running unmodified. This patch
> brings the error forward to...the same function call it was failing at
> before ('cause of an undefined constant). Oh well. It might be trivial
> to get past that point, but I'm done for today.
>
> This brings us *much* closer to a full socket implementation. Here's the
> status:
>
> General differences:
>
> All places where C Ruby had struct sockaddr use java.net.InetSocketAddress
>
> All functions which are supposed to return a CNAME and aliases return an
> empty array for aliases.
>
> All functions which can use a symbolic port only work with numeric ports.
> Ditto for return values.
>
> Functions which take optional flags ignore the flags.
>
> A few constants on BasicSocket don't exist.
>
> Methods which are unimplemented or implemented with caveats:
>
> BasicSocket#for_fd
> BasicSocket#close_read -- isn't used in any of the standard libraries;
> does anything need this?
> BasicSocket#close_write -- isn't used in any of the standard libraries;
> does anything need this?
> BasicSocket#shutdown -- works with how=2 (default); does anything use it
> any other way?
> BasicSocket#setsockopt
> BasicSocket#getsockopt -- isn't used in any of the standard libraries; we
> wouldn't implement it like C anyway
>
> IPSocket#recvfrom
>
> TCPServer#sysaccept
> TCPServer#listen
>
> UDPSocket -- no implementation at all...
>
> Socket.socketpair
> Socket.pair
> Socket.getservbyname -- AFAIK, this doesn't have a java equivalent.
> Socket.sockaddr_in
> Socket.pack_sockaddr_in
> Socket.unpack_sockaddr_in
>
> The following methods are all low-level C-style calls, intended to allow
> Ruby to get at platform-specific sockets. If we implement them, we should
> be able to assume the user knows they're in JRuby and not C Ruby, and can
> expect different behaviour. I don't know of any major ruby program or
> library which uses them.
>
> Socket.new
> Socket.open
> Socket#connect
> Socket#bind
> Socket#listen
> Socket#accept
> Socket#sysaccept
> Socket#recvfrom
>
> And then of course, there's the stickiest: Kernel#select
>
> Anyway, have fun!
>
> Evan
--
+ http://www.tc.umn.edu/~enebo +---- mailto:[EMAIL PROTECTED] ----+
| Thomas E Enebo, Protagonist | "Luck favors the prepared |
| | mind." -Louis Pasteur |
-------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Jruby-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jruby-devel
