[ruby-dev:12902] Re: recursive malloc / fork deadlock / thread deadlock

In message <[e-mail]>
	on Thu, 12 Apr 2001 15:32:03 +0900,
	GOTOU Yuuzou <[e-mail]> wrote:
> > > setbuf/setvbufでバッファにNULLを指定している
> > > 	→ stdioのバッファリングを殺している。
> > > 
> > > という、認識で間違いないですよね。
と書いたのは私ですが、これは誤りでした。

> わたしはそういう意図はありませんでした。実際、_IONBF
> にするとシステムの CPU 時間が秒単位でかかるようになり
> ました。
混乱させて申し訳ありません。

> > これが必要なのはFreeBSDだけなので、#ifdef, #endifで囲むって手もありま
> > すね。
> 
> 確認した範囲では NetBSD と Solaris にも同様の修正は必
> 要です。
おそらくOpenBSDも一緒でしょう。

> FreeBSD の実装では サイズが 0 の場合は内部で BUFSIZ 分
> のバッファを確保するようになってるみたいなので、それと
> 同じ効果が得られると思ったのですが、不思議です。
ファイルシステムのブロックサイズから引っ張って来る場合もあるようです。
(だからといって効率が落ちる理由にはならない...)

逆に常にフルにバッファリングすることが逆効果となる場合はありそうな気が
します。

> ちなみに、C99 には次のようにあって、特に食い違ってはい
> ないような気がしますが、やっぱり #ifdef でくくって
> BUFSIZ を指定するのが無難でしょうか。
NetBSDのsetvbuf(3)によると、

     bytes long; this buffer will be used instead of the current buffer.  (If
     the size argument is not zero but buf is NULL, a buffer of the given size
     will be allocated immediately, and released on close.  This is an exten-
     sion to ANSI C; portable code should use a size of 0 with any NULL
     buffer.)

とあって、sizeをゼロでない値としてbufにNULLを指定することで、即座にバッ
ファの割り当てを受けると期待することの方が拡張だという記述があります。
従って、sizeをゼロで、bufはNULLの方が移植性という面では良さそうに思え
ます。

--
神戸 隆博(かんべ たかひろ)		at 仕事場