[#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:26263] Re: IO.select dumps core

From: nobu@...
Date: 2005-06-01 23:21:29 UTC
List: ruby-dev #26263
なかだです。

At Thu, 2 Jun 2005 04:18:40 +0900,
Tanaka Akira wrote in [ruby-dev:26262]:
> 基本的な方針は「なぜか余計にメモリを確保しておいて動いたらラッキー」な
> ので、今まで参照していなかった FD_SETSIZE は今さら参照しなくても書ける
> はずなんじゃないかと思います。

あまりFD_SETSIZEを避ける必要もないとは思いますが。

> FD_ZERO による初期状態が 0 の並びでない可能性を考慮するなら、FD_ZERO
> は常に行うべきでしょう。
> 
>     if (fds->fdset) {
> 	MEMZERO(fds->fdset, fd_mask, howmany(fds->maxfd, NFDBITS));
> 	FD_ZERO(fds->fdset);
>     }

そうかも。

> >> # Windows の fd_set は違うというので探したら、
> >> # http://msdn.microsoft.com/library/en-us/winsock/winsock/fd_set_2.asp
> >> # を見る限りは MEMZERO だけでよさそうですねぇ。
> >
> > そもそもwinsockがFD_SETSIZE以上を見てくれるかどうか、というより
> > もWaitForMultipleObjects()が見てくれなさげ。
> 
> MEMZERO だけでいいというのは、FD_ZERO と同等の効果がありそうだ、という
> 意味です。

いや、そもそもWindowsではFD_SETSIZE以上を渡しても意味はないし、
FD_SET()でも単純に無視しているので、この変更の対象外という意味
です。というかそのためにNFDBITSで分けてます。

どちらかといえば、[ruby-core:05088]のようにselect()がソケットし
か扱えない環境では、ソケット以外を別扱いにするコードを含めたほ
うがいいのかも知れません。

> FD_SETSIZE以上のサポートを広げるという意味では、poll にする意味が有る
> かというのが興味の有るところなのですが、Windows は救えなさそうですね。
> (そもそも Windows に poll があるのかどうか知りませんが)

システム自体が64までしかサポートしないので、native threadを立ち
上げてカスケードするしかなさそうです。

> poll にすれば救える環境って存在するのかなぁ?

SysVベース?

-- 
--- 僕の前にBugはない。
--- 僕の後ろにBugはできる。
    中田 伸悦

In This Thread