Aside from this issue, I noticed this patch only sets the socket non-blocking without changing the behavior of some of the functions. Channel.read() is closer to recv(), so when we do sysread() or read(), we loop over Channel.read(). If the Channel is non-blocking, that means we just spin (this could maybe account for the 99% CPU that someone was mentioning?).
I'm going to try and write a patch that will configure non-blocking and avoid these issues. Hopefully I'll have it later today.
Evan
On 6/16/06, Charles O Nutter <[EMAIL PROTECTED]> wrote:
Do whatever Ruby does :)On 6/16/06, Evan Buswell < [EMAIL PROTECTED]> wrote:I'm on vacation so I haven't had a chance to look at this patch.
Beware that there are issues with nonblocking io and select(). While a
SocketChannel is being select()ed, it *must* be in nonblocking mode. I
was thinking about implementing fcntl for nonblocking io, but the
problem is what if while one thread is select()ing on a socket, another
sets the socket blocking? Either we have to block the fcntl until the
select completes or we have to do some weird threading delay-set magic.
Granted there might not be one single instance of something like this
happening, but then again there might.
Evan--
Charles Oliver Nutter @ headius.blogspot.com
JRuby Developer @ jruby.sourceforge.net
Application Architect @ www.ventera.com
_______________________________________________
Jruby-devel mailing list
Jruby-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jruby-devel
--
Evan Buswell
[EMAIL PROTECTED]
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 Jruby-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jruby-devel
