[#205] openbsd system call changes — Jamie Herre <jfh@...>
Hi,
7 messages
2002/07/05
[#216] lib/mkfm.rb: have_bin()/find_bin() — Sean Chittenden <sean@...>
This could be me over looking something, but in mkmf.rb, there is no
7 messages
2002/07/07
[#221] Wiring up the Boehm GC to the Ruby interpreter — Matthew Bloch <matthew@...>(by way of Matthew Bloch <mattbee@...>)
Hi there;
4 messages
2002/07/12
[#228] Patch to stop TCPSocket.new blocking on DNS lookups — Matthew Bloch <mattbee@...>
Hello;
6 messages
2002/07/17
[#237] object.c ruby.h (fwd) — Robert Skarwecki <skaav@...>
Hello everybody,
42 messages
2002/07/24
[#239] Re: [PATCH] object.c ruby.h (fwd)
— GOTO Kentaro <gotoken@...>
2002/07/24
At Thu, 25 Jul 2002 00:02:28 +0900,
[#240] Re: [PATCH] object.c ruby.h (fwd)
— Dave Thomas <Dave@...>
2002/07/24
GOTO Kentaro <gotoken@notwork.org> writes:
[#246] Re: [PATCH] object.c ruby.h (fwd)
— GOTO Kentaro <gotoken@...>
2002/07/25
At Thu, 25 Jul 2002 05:05:46 +0900,
[#247] Re: [PATCH] object.c ruby.h (fwd)
— Dave Thomas <Dave@...>
2002/07/25
GOTO Kentaro <gotoken@notwork.org> writes:
[#248] Re: [PATCH] object.c ruby.h (fwd)
— nobu.nokada@...
2002/07/25
Hi,
[#249] Re: [PATCH] object.c ruby.h (fwd)
— Dave Thomas <Dave@...>
2002/07/25
nobu.nokada@softhome.net writes:
[#250] Re: [PATCH] object.c ruby.h (fwd)
— nobu.nokada@...
2002/07/25
Hi,
[#252] Re: [PATCH] object.c ruby.h (fwd)
— GOTO Kentaro <gotoken@...>
2002/07/25
At Fri, 26 Jul 2002 03:11:02 +0900,
[#253] Re: [PATCH] object.c ruby.h (fwd)
— Dave Thomas <Dave@...>
2002/07/25
GOTO Kentaro <gotoken@notwork.org> writes:
[#255] Re: [PATCH] object.c ruby.h (fwd)
— GOTO Kentaro <gotoken@...>
2002/07/25
At Fri, 26 Jul 2002 05:34:10 +0900,
[#268] Re: [PATCH] object.c ruby.h (fwd)
— Masaki Suketa <masaki.suketa@...>
2002/07/27
In message "Re: [PATCH] object.c ruby.h (fwd)"
[#269] Re: [PATCH] object.c ruby.h (fwd)
— Dave Thomas <Dave@...>
2002/07/27
Masaki Suketa <masaki.suketa@nifty.ne.jp> writes:
[#288] Re: [PATCH] object.c ruby.h (fwd)
— Masaki Suketa <masaki.suketa@...>
2002/08/03
In message "Re: [PATCH] object.c ruby.h (fwd)"
[#295] Re: [PATCH] object.c ruby.h (fwd)
— "NAKAMURA, Hiroshi" <nahi@...>
2002/08/05
Hi,
[#260] Re: [PATCH] object.c ruby.h (fwd)
— kjana@...4lab.to (YANAGAWA Kazuhisa)
2002/07/26
In message <m2bs8vr1h7.fsf@zip.local.thomases.com>
[#279] A truth? patch + benchmarks
— "Christoph" <chr_news@...>
2002/07/31
[#280] Re: A truth? patch + benchmarks
— ts <decoux@...>
2002/07/31
>>>>> "C" == Christoph <chr_news@gmx.net> writes:
[#283] RE: A truth? patch + benchmarks
— "Christoph" <chr_news@...>
2002/08/01
[#241] Compiling ruby on SGI origins — Bil Kleb <W.L.Kleb@...>
I just tried compiling ruby-1.6.7 on a couple SGI origins (mips-sgi-irix6.5),
6 messages
2002/07/25
Re: Patch to stop TCPSocket.new blocking on DNS lookups
From:
Matthew Bloch <mattbee@...>
Date:
2002-07-17 14:23:09 UTC
List:
ruby-core #230
On Wednesday 17 July 2002 14:12, you wrote:
> Hi,
>
> In message "Patch to stop TCPSocket.new blocking on DNS lookups"
>
> on 02/07/17, Matthew Bloch <mattbee@soup-kitchen.net> writes:
> |I'm using Ruby for a multi-threaded (50 or 60 threads at once) web spider
> | and found that every time I started a fetch in a thread, the whole
> | process got blocked on getaddrinfo, which of course knackers the
> | throughput since all the already-connected threads have to wait for a
> | single DNS lookup to happen.
>
> How about using "Socket.do_not_reverse_lookup = true"?
The delays I'm experiencing were due to (necessary) forward lookups as far as
I'm aware: my test program looks like this:
-----------------------------------------------------------
require 'socket'
t = Thread.new {
count = 0
loop {
print "count = #{count += 1}\n"
sleep 0.05
}
}
ARGV.each { |name|
sock = TCPSocket.new(name, 80) # forward lookup here?
print "connected to #{name}\n"
sock.print "GET /\n\n"
sock.each { |l| print "#{l}\n" }
sock.close
}
t.join
-----------------------------------------------------------
With the unpatched Ruby, my counter thread paused before every connection.
Patched, it carries on fine and still returns the results. As I said this is
the only testing I've done on it so far.
--
Matthew Bloch Bytemark Computer Consulting Limited
http://www.bytemark.co.uk/
tel. +44 (0) 8707 455026