If you were to tackle a NIO IOHandler, you'd be a lot of people's
hero. The move to NIO is not a maybe, it's a must...there's simple too
much in Ruby we can't implement without it. We've already started to
use NIO in a few places for things like file locking, so we're on the
way there already. In addition, with the more "advanced" VM features
we've got planned in the future, managing IO at a lower level will be
absolutely necessary.
If you don't get around to it, we certainly will...but it might be a
little while. Keep us updated.
Also, if you have an updated patch, please send it...I promise we'll
look it over and get it included.
On 4/30/06, Evan Buswell <[EMAIL PROTECTED]> wrote:
Poking around a bit more, I defined AI_PASSIVE to some dummy value and now
WEBrick::GenericServer runs up to the point of select(...). Of course,
this is no big deal since we already knew it was going to fail on select
and that's the sticky point here anyway.
The select() in question is on TCPServer objects, so doing a workaround
with InputStream.available isn't going to work. As far as I can tell, we
need to break out nio.
nio looks like its a Good Thing, and will simplify a lot of the IO code
already there. But of course, that's a large amount of code to migrate
just to make 1 function work. We can get away with a socket-only
nio-based select (who uses select on files anyway??) w/o changing any of
the other IO code. I'll look into it, but really I should just implement
an IOHandler which uses nio; it'd be a much cleaner solution and de-uglify
the send / recv code I wrote, as well as providing trivial support for
UDPSocket and SSLSocket (based on java.net.ssl...)
Evan
Thomas E Enebo wrote:
> 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
>
-------------------------------------------------------
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?cmdlnk&kid0709&bid&3057&dat1642
_______________________________________________
Jruby-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jruby-devel
--
Charles Oliver Nutter @ headius.blogspot.com
JRuby Developer @ jruby.sourceforge.net
Application Architect @ www.ventera.com
-------------------------------------------------------
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&kid0709&bid&3057&dat1642
_______________________________________________
Jruby-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/jruby-devel
