[ruby-dev:12903] 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のバッファリングを殺している。
> > > > 
> > > > という、認識で間違いないですよね。
> と書いたのは私ですが、これは誤りでした。

すみません。私がマッチ程度の火に、ガソリンぶっかけたんじゃないかという
気がします。

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

ファイル構造体の示している実体がttyの場合または文字列などを疑似的にファ
イルに見せている場合には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の方が移植性という面では良さそうに思え
> ます。

先のメールではFreeBSDに特化するのであれば、固有の機能も使えるよなと思っ
ただけの話です(そっちの方が速いのかと勘違いした)。指定するとしても、
BUFSIZではなくて、stat.st_blksizeより大きい値を指定しない限りは、速く
なる方向に転ぶことはないんだと思います。NetBSD, OpenBSD,Solarisなども
考慮するのであれば、共通仕様に従った方がよいと思います。

＃他に遅くなる要因って、setvbufの中のFLOCKFILEって関係しますかね？
--
*------*				[e-mail]
|人∧鷲|				沖データ ソフトウェア開発２部
| <女> |				安達 淳
|牛∨獅|
*------*