[#26266] pragma on ripper — nobuyoshi nakada <nobuyoshi.nakada@...>

なかだです。

15 messages 2005/06/02

[#26312] rb_gc_mark_threads spin — Tanaka Akira <akr@...17n.org>

最近、とあるプログラム(五月雨)が、無限ループに陥ることが何回かありました。

32 messages 2005/06/09
[#26323] Re: rb_gc_mark_threads spin — Tanaka Akira <akr@...17n.org> 2005/06/10

In article <TYOMLEM04Rqf69aZbLA0000002d@tyomlvem02.e2k.ad.ge.com>,

[#26329] Re: rb_gc_mark_threads spin — nobu@... 2005/06/10

なかだです。

[#26331] Re: rb_gc_mark_threads spin — Tanaka Akira <akr@...17n.org> 2005/06/11

In article <200506101543.j5AFhToG009328@sharui.nakada.niregi.kanuma.tochigi.jp>,

[#26333] Re: rb_gc_mark_threads spin — Tanaka Akira <akr@...17n.org> 2005/06/11

In article <8764wlil9l.fsf@m17n.org>,

[#26334] Re: rb_gc_mark_threads spin — nobu@... 2005/06/11

なかだです。

[#26337] Re: rb_gc_mark_threads spin — Tanaka Akira <akr@...17n.org> 2005/06/11

In article <200506111335.j5BDZkoG019423@sharui.nakada.niregi.kanuma.tochigi.jp>,

[#26405] WEBrick DoS vulnerability — Tanaka Akira <akr@...17n.org>

NetBSD 2.0 で WEBrick を使って HTTP サーバを動かした場合、クライアント

24 messages 2005/06/29
[#26477] Re: WEBrick DoS vulnerability — GOTOU Yuuzou <gotoyuzo@...> 2005/07/08

ごとうゆうぞうです。

[#26480] Re: WEBrick DoS vulnerability — Tanaka Akira <akr@...17n.org> 2005/07/08

In article <20050708.175802.957830318.gotoyuzo@sawara.does.notwork.org>,

[#26481] Re: WEBrick DoS vulnerability — GOTOU Yuuzou <gotoyuzo@...> 2005/07/08

In message <87fyupzgcq.fsf@m17n.org>,

[#26421] Subversion — Shugo Maeda <shugo@...>

前田です。

24 messages 2005/06/30
[#26422] Re: Subversion — Yukihiro Matsumoto <matz@...> 2005/06/30

まつもと ゆきひろです

[#26423] Re: Subversion — "U.Nakamura" <usa@...> 2005/06/30

こんにちは、なかむら(う)です。

[ruby-dev:26404] Re: IO.select dumps core

From: Tanaka Akira <akr@...17n.org>
Date: 2005-06-29 15:43:37 UTC
List: ruby-dev #26404
In article <20050628225134.710a4ab2.tommy@tmtm.org>,
  とみたまさひろ <tommy@tmtm.org> writes:

> [ruby-dev:26398] のように、コンパイル時に FD_SETSIZE を増加させてみた
> ところ、3000 くらいでも正常に動作しました。

ふむ。sys/select.h を見直してみたところ... Solaris って FD_SETSIZE を
増加させた時は select が select_large_fdset を使うように変わるんですね。
これは初めて知りました。

> poll() でなく select() のまま行くとしたら、Ruby の make 時に 
> FD_SETSIZE をいくつにするかが問題でしょうか。最大の 65536 にすると 
> fd_set 一つあたり 8KB の領域を食います(標準では 128B)。

メモリについては動的に必要な量を計算して確保すればいいんじゃないでしょ
うか。Ruby 1.9 には実装済みですし。

とすれば、あとは select_large_fdset を使うようにすればいいわけで、こん
なかんじでしょうか。個人的に試せる環境がないので確認がとれないのがつら
いところですが。

Index: configure.in
===================================================================
RCS file: /src/ruby/configure.in,v
retrieving revision 1.279
diff -u -r1.279 configure.in
--- configure.in	12 Jun 2005 16:56:06 -0000	1.279
+++ configure.in	29 Jun 2005 15:31:11 -0000
@@ -492,7 +492,7 @@
 	      getpriority getrlimit setrlimit\
 	      dlopen sigprocmask sigaction _setjmp\
 	      setsid telldir seekdir fchmod mktime timegm cosh sinh tanh\
-	      setuid setgid daemon \
+	      setuid setgid daemon select_large_fdset \
 	      _UNW_createContextForSelf)
 AC_ARG_ENABLE(setreuid,
        [  --enable-setreuid       use setreuid()/setregid() according to need even if obsolete.],
Index: eval.c
===================================================================
RCS file: /src/ruby/eval.c,v
retrieving revision 1.792
diff -u -r1.792 eval.c
--- eval.c	28 Jun 2005 13:08:32 -0000	1.792
+++ eval.c	29 Jun 2005 15:31:11 -0000
@@ -179,6 +179,10 @@
 #include <sys/select.h>
 #endif
 
+#ifdef HAVE_SELECT_LARGE_FDSET
+#define select select_large_fdset
+#endif
+
 #ifdef HAVE_SYS_PARAM_H
 #include <sys/param.h>
 #endif

まぁ、こういう対処より poll を使うほうがいい、というのはひとつの見識だ
とは思います。
-- 
[田中 哲][たなか あきら][Tanaka Akira]

In This Thread