[#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
Patch to stop TCPSocket.new blocking on DNS lookups
From:
Matthew Bloch <mattbee@...>
Date:
2002-07-17 10:31:34 UTC
List:
ruby-core #228
Hello;
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.
So after a bit of experimenting I've made a patch which calls getaddrinfo_a
(a GNU extension) and lets the other threads run while a lookup is going on.
I'll post it today after I've tested it on my spider. I'm a bit uneasy
about the implementation though:
in ext/socket/socket.c
*) changed getaddrinfo calls to ruby_nonblock_getaddrinfo;
*) implmeneted ruby_nonblock_getaddrinfo:
sets up a call to getaddrinfo_a for the query and asks to be notified
by SIGUSR2;
while (request is in progress) calls rb_thread_wait_signal("USR2")
returns with result
in eval.c:
*) added WAIT_SIGNAL constant and a 'char* signal' field in struct thread to
indicate which signal a thread is waiting for;
*) added static wakeup_threads_sleeping_on_signal which is called from
rb_signal_raise every time a signal comes in to wake any threads that
are interested in that signal;
*) implemented ruby_thread_wait_signal: just sets the thread status to stopped
and calls rb_thread_schedule().
Okay, for one being notified by a signal makes me a little nervous; I'm not
sure there aren't race conditions in waiting for the signal until a request
is done. Also, fencing off a hard-coded signal for our use like that is not
very flexible when there are other calls in socket.c which could benefit from
being made asychronous in the same manner. And of course there's the fact
that there's no Win32 implementation (or does Win32 sockets do asychronous
DNS already?).
getaddrinfo_a can also notify us by calling a function in another kernel
thread; would this be preferable?
Any ideas appreciated.
cheers,
--
Matthew Bloch Bytemark Computer Consulting Limited
http://www.bytemark.co.uk/
tel. +44 (0) 8707 455026