[#47869] [Mac OS X] Dir.glob で取得したファイル名のバイト列が異なる — Watson <watson1978@...>
Ruby 2.0 =1B$B$^$G$O=1B(B OS X =1B$B$N%U%!%$%kL>$r=1B(B Dir.glob =
7 messages
2014/01/03
[#47875] Re: [Mac OS X] Dir.glob で取得したファイル名のバイト列が異なる
— "NARUSE, Yui" <naruse@...>
2014/01/09
端的には仕様変更です。
[#47876] Re: [Mac OS X] Dir.glob で取得したファイル名のバイト列が異なる
— Watson <watson1978@...>
2014/01/09
ご返答ありがとうございます。
[#47903] Re: [ruby-cvs:51792] nobu:r44647 (trunk): socket/option.c: socket option variations — Tanaka Akira <akr@...>
2014/1/19 <nobu@ruby-lang.org>:
7 messages
2014/01/19
[#47904] Re: [ruby-cvs:51792] nobu:r44647 (trunk): socket/option.c: socket option variations
— Nobuyoshi Nakada <nobu@...>
2014/01/19
(2014/01/19 10:17), Tanaka Akira wrote:
[#47905] Re: [ruby-cvs:51792] nobu:r44647 (trunk): socket/option.c: socket option variations
— Tanaka Akira <akr@...>
2014/01/19
2014年1月19日 16:20 Nobuyoshi Nakada <nobu@ruby-lang.org>:
[#47907] Re: [ruby-cvs:51792] nobu:r44647 (trunk): socket/option.c: socket option variations
— Nobuyoshi Nakada <nobu@...>
2014/01/19
(2014/01/19 16:48), Tanaka Akira wrote:
[#47908] Re: [ruby-cvs:51792] nobu:r44647 (trunk): socket/option.c: socket option variations
— Tanaka Akira <akr@...>
2014/01/19
2014年1月19日 18:12 Nobuyoshi Nakada <nobu@ruby-lang.org>:
[#47917] Re: [ruby-changes:32633] nobu:r44712 (trunk): thread_pthread.c: get current main thread stack size — KOSAKI Motohiro <kosaki.motohiro@...>
Ruby-devに河岸をうつしました。
5 messages
2014/01/28
[#47918] Re: [ruby-changes:32633] nobu:r44712 (trunk): thread_pthread.c: get current main thread stack size
— Nobuyoshi Nakada <nobu@...>
2014/01/28
なかだです。
[#47919] Re: [ruby-changes:32633] nobu:r44712 (trunk): thread_pthread.c: get current main thread stack size
— "NARUSE, Yui" <naruse@...>
2014/01/28
スレッドのスタック情報の取得は前にまとめたことがありますが、
[ruby-dev:47918] Re: [ruby-changes:32633] nobu:r44712 (trunk): thread_pthread.c: get current main thread stack size
From:
Nobuyoshi Nakada <nobu@...>
Date:
2014-01-28 07:40:04 UTC
List:
ruby-dev #47918
なかだです。
(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はできる。
中田 伸悦