Tom went ahead and applied this patch last night, so I just gave it a whirl. It definitely appears to be working well.[EMAIL PROTECTED]:~/workspace/jruby$ time gem install --version=1.1.2 rails --include-dependencies --no-rdoc
...real 0m47.541suser 0m30.322ssys 0m3.336sOn this same system
Very, very cool. That was my understanding of sysread as well. I was confused, as you could imagine, why when I made the socket nonblocking there were no issues. Your explanation that Ruby wanted UP TO n bytes makes sense now; nonblocking allowed it to return just what it had available, and make it
Yep. I've tested this with net/http which was blocking forever before -- now it downloads as fast as it ought.
EvanOn 6/27/06, Evan Buswell <[EMAIL PROTECTED]> wrote:
Yeah, about 2 minutes after I sent that I realized that was your change and it had reason for being there. Sorry.
The problem is
Yeah, about 2 minutes after I sent that I realized that was your change and it had reason for being there. Sorry.
The problem isn't the blocking channel, its my sysread function.
Here's the deal: I was under the impression sysread(20) meant block
till you read 20, otherwise what distinguishes it
The Selectable nonblocking thing was my contribution to fix the fact that sockets were blocking by default. This caused a final read from the socket to block until Ruby's timeout.rb thread interrupted it, causing the gem exception that didn't seem to hurt anything. Setting the channel nonblocking f
Patch is attached.
I noticed that code somehow crept in to set selectable channels
nonblocking by default (probably my fault). This may be part of
the problem with the exception being thrown at the end of the gem
download. This is also fixed in this patch.
The approach I took here is to have a
Sounds good on all points. We may or may not ship 0.9.0 with your updated patch (probably not) but we have seen no issues from my admittedly naive attempt. Get your patch over to us whenever you can, but don't worry about holding up the release.
On 6/27/06, Evan Buswell <[EMAIL PROTECTED]> wrote:
T
That's the problem. AFAIK, C select() on which Ruby's is based
makes no requirements about blocking/non-blocking, so this is only an
issue in Java, where if we are doing a select(), the socket must be
nonblocking, and if we set the socket blocking while in the middle of a
select, an exception is t
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 aSocketChannel is being select()ed, it *must* be in nonblocking mode. I
was thinking abo
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 whil
I had thought I had webrick working fairly well, but did not
see the fcntl problem. It is cool we can support non-blocking.
I can apply the patch (from your other thread) this evening
(I am out of town on an unexpected business trip).
-Tom
On Tue, 13 Jun 2006, Ola Bini defenestrated me:
>
I wouldn't be surprised if WEBrick is also using that timeout package. You could try commenting out all the threading weirdness in timeout.rb, and I'd bet the exceptions go away.Given that an InterruptedException is almost always going to mean a thread is being terminated in JRuby, it might be acce
12 matches
Mail list logo
