[ruby-dev:47920] Re: [ruby-changes:32633] nobu:r44712 (trunk): thread_pthread.c: get current main thread stack size

そういえば、先に挙げた日記にも書いていますが、最近のOS Xはrlimit叩かなくても、
pthread_get_stacksize_np(3) でスレッドごとのスタックサイズが取れるようです。
ソース見てもいかにもとれてそうな雰囲気。
http://www.opensource.apple.com/source/Libc/Libc-825.40.1/pthreads/pthread.c

2014年1月28日 17:49 NARUSE, Yui <[e-mail]>:
> スレッドのスタック情報の取得は前にまとめたことがありますが、
> http://d.hatena.ne.jp/nurse/20100204
> OSごとの依存が激しいので、下手に抽象化せずOSごとにがっつり分岐して
> 書いていただいたほうがいいと思います。
>
> あと、どのOSを念頭にいじったのかは絶対に書いてください。
> 書いてくれないとまた壊すので。
>
> 2014年1月28日 16:40 Nobuyoshi Nakada <[e-mail]>:
>> なかだです。
>>
>> (2014/01/28 10:06), KOSAKI Motohiro wrote:
>>> まず、単純にifdefにRLIMIT_STACKの有無が抜けているというのもあるが、
>>> メインスレッドならRLIM_STACKで取れるというのがLinux固有なので、
>>> それはHAVE_GETRLIMITとかの機能有無じゃなく、ifdef linux でないと
>>> おかしいように思える。
>>
>> そこはlinuxではなくMacOS X用でした。linuxでは解決していなかったので、
>> r44726で再修正してみました。
>>
>>> Linuxだとrlim_curがulongでinfinityが-1だからつまりULONG_MAX扱いになって
>>> 常にオーバーフロー扱いにならない。
>>> というか RLIM_INFINITY の値はOS依存だから大小比較するまえに
>>> if (rlim.rlim_cur == RLIM_INFINITY) とかないとおかしくないですか？
>>
>> 試した限りではOS XではRLIM_INFINITYにはならないようですが、後で考えてみ
>> ます。
>>
>>> 次に、get_stack()で使っているpthread_getattr_np()はもうちょっと賢いことをやっていて、
>>> /proc/self/mapsみてVMAのサイズを超えないように調整してる。これを避けたのは
>>> たぶん、シグナルコンテキストというのを意識したのだと思うし、それは正しいと
>>> 思うのだけど、ちょっとラフすぎる印象。
>>
>> それは気づいてませんでした。ruby_stack_overflowed_p()ではget_stack()は
>> 避けるべきかも…。
>>
>>> どうせ current threadとれないときは、get_stack呼んじゃってるんだから、これだったら
>>> メインスレッドのケースも get_stack呼んでしまったほうが誤判定減るように思えます。
>>
>> 今はそんな感じです。
>>
>> --
>> --- 僕の前にBugはない。
>> --- 僕の後ろにBugはできる。
>>     中田 伸悦
>
>
>
> --
> NARUSE, Yui  <[e-mail]>



-- 
NARUSE, Yui  <[e-mail]>