QA@IT
«回答へ戻る

文章が尻切れだったのを修正.

180
 
 まぁ,そういう原理原則のを踏まえて,手元でやってみたところ,Ruby の開発版(ruby 2.0.0dev (2012-06-20 trunk 36148) [i386-mswin32_100])では,ちゃんと sleep の前に GC されました.
 
-で,この例は,Shu さんは消えると不味い,と仰っていますが,このタイミングでは外からアクセスする方法はないので(たとえば,ローカル変数に代入している場合は参照される可能性がありますが,この場合はどこにも参照されません).kenn さんの「TOPLEVEL_BINDING と関係あるか?」という話ですが,この場合は関係ありません.多分.
+で,この例は,Shu さんは消えると不味い,と仰っていますが,このタイミングでは外からアクセスする方法はないので(たとえば,ローカル変数に代入している場合は参照される可能性がありますが,この場合はどこにも参照されません.これは,トップレベルなスコープも,メソッドローカルなスコープも関係ありません),GC されても問題無いです.kenn さんの「TOPLEVEL_BINDING と関係あるか?」という話ですが,この場合は関係ありません.多分.
 
 *1: 運と書きましたが,厳密には OS やらコンパイラやらの実装などが絡みます.あと,もちろん Ruby のバージョンも大いに関係します.その日の運にも依存する場合がありますので,星占いなども参考になるかもしれません.
 

一般的に,Ruby の GC では「人間が見て GC されてもいいんじゃないの」と思うタイミングではなく,「処理系によって,確実に GC しても良さそうだ」,と理解したタイミングで GC されます.なので,運 (*1) とかが絡みます.

まぁ,そういう原理原則のを踏まえて,手元でやってみたところ,Ruby の開発版(ruby 2.0.0dev (2012-06-20 trunk 36148) [i386-mswin32_100])では,ちゃんと sleep の前に GC されました.

で,この例は,Shu さんは消えると不味い,と仰っていますが,このタイミングでは外からアクセスする方法はないので(たとえば,ローカル変数に代入している場合は参照される可能性がありますが,この場合はどこにも参照されません.これは,トップレベルなスコープも,メソッドローカルなスコープも関係ありません),GC されても問題無いです.kenn さんの「TOPLEVEL_BINDING と関係あるか?」という話ですが,この場合は関係ありません.多分.

*1: 運と書きましたが,厳密には OS やらコンパイラやらの実装などが絡みます.あと,もちろん Ruby のバージョンも大いに関係します.その日の運にも依存する場合がありますので,星占いなども参考になるかもしれません.

こんなわけで,オブジェクトが GC されるタイミングは運によってしまうので,オブジェクトの後始末を特定のタイミングで行いたいときは,ファイナライザなどに頼らず,きちんと後始末処理を ensure 節などで書くことをお勧めします.

一般的に,Ruby の GC では「人間が見て GC されてもいいんじゃないの」と思うタイミングではなく,「処理系によって,確実に GC しても良さそうだ」,と理解したタイミングで GC されます.なので,運 (*1) とかが絡みます.

まぁ,そういう原理原則のを踏まえて,手元でやってみたところ,Ruby の開発版(ruby 2.0.0dev (2012-06-20 trunk 36148) [i386-mswin32_100])では,ちゃんと sleep の前に GC されました.

で,この例は,Shu さんは消えると不味い,と仰っていますが,このタイミングでは外からアクセスする方法はないので(たとえば,ローカル変数に代入している場合は参照される可能性がありますが,この場合はどこにも参照されません.これは,トップレベルなスコープも,メソッドローカルなスコープも関係ありません),GC されても問題無いです.kenn さんの「TOPLEVEL_BINDING と関係あるか?」という話ですが,この場合は関係ありません.多分.

*1: 運と書きましたが,厳密には OS やらコンパイラやらの実装などが絡みます.あと,もちろん Ruby のバージョンも大いに関係します.その日の運にも依存する場合がありますので,星占いなども参考になるかもしれません.

こんなわけで,オブジェクトが GC されるタイミングは運によってしまうので,オブジェクトの後始末を特定のタイミングで行いたいときは,ファイナライザなどに頼らず,きちんと後始末処理を ensure 節などで書くことをお勧めします.

表現が微妙だったのを修正.

180
 
 *1: 運と書きましたが,厳密には OS やらコンパイラやらの実装などが絡みます.あと,もちろん Ruby のバージョンも大いに関係します.その日の運にも依存する場合がありますので,星占いなども参考になるかもしれません.
 
-こんなわけで,オブジェクトが GC されるタイミングは運によってしまうので,オブジェクトの後始末を特定の箇所でしたいときは,ファイナライザなどに頼らず,きちんと後始末処理を ensure 節などで書くことをお勧めします.
+こんなわけで,オブジェクトが GC されるタイミングは運によってしまうので,オブジェクトの後始末を特定のタイミングで行いたいときは,ファイナライザなどに頼らず,きちんと後始末処理を ensure 節などで書くことをお勧めします.

一般的に,Ruby の GC では「人間が見て GC されてもいいんじゃないの」と思うタイミングではなく,「処理系によって,確実に GC しても良さそうだ」,と理解したタイミングで GC されます.なので,運 (*1) とかが絡みます.

まぁ,そういう原理原則のを踏まえて,手元でやってみたところ,Ruby の開発版(ruby 2.0.0dev (2012-06-20 trunk 36148) [i386-mswin32_100])では,ちゃんと sleep の前に GC されました.

で,この例は,Shu さんは消えると不味い,と仰っていますが,このタイミングでは外からアクセスする方法はないので(たとえば,ローカル変数に代入している場合は参照される可能性がありますが,この場合はどこにも参照されません).kenn さんの「TOPLEVEL_BINDING と関係あるか?」という話ですが,この場合は関係ありません.多分.

*1: 運と書きましたが,厳密には OS やらコンパイラやらの実装などが絡みます.あと,もちろん Ruby のバージョンも大いに関係します.その日の運にも依存する場合がありますので,星占いなども参考になるかもしれません.

こんなわけで,オブジェクトが GC されるタイミングは運によってしまうので,オブジェクトの後始末を特定のタイミングで行いたいときは,ファイナライザなどに頼らず,きちんと後始末処理を ensure 節などで書くことをお勧めします.

一般的に,Ruby の GC では「人間が見て GC されてもいいんじゃないの」と思うタイミングではなく,「処理系によって,確実に GC しても良さそうだ」,と理解したタイミングで GC されます.なので,運 (*1) とかが絡みます.

まぁ,そういう原理原則のを踏まえて,手元でやってみたところ,Ruby の開発版(ruby 2.0.0dev (2012-06-20 trunk 36148) [i386-mswin32_100])では,ちゃんと sleep の前に GC されました.

で,この例は,Shu さんは消えると不味い,と仰っていますが,このタイミングでは外からアクセスする方法はないので(たとえば,ローカル変数に代入している場合は参照される可能性がありますが,この場合はどこにも参照されません).kenn さんの「TOPLEVEL_BINDING と関係あるか?」という話ですが,この場合は関係ありません.多分.

*1: 運と書きましたが,厳密には OS やらコンパイラやらの実装などが絡みます.あと,もちろん Ruby のバージョンも大いに関係します.その日の運にも依存する場合がありますので,星占いなども参考になるかもしれません.

こんなわけで,オブジェクトが GC されるタイミングは運によってしまうので,オブジェクトの後始末を特定のタイミングで行いたいときは,ファイナライザなどに頼らず,きちんと後始末処理を ensure 節などで書くことをお勧めします.

回答を投稿

一般的に,Ruby の GC では「人間が見て GC されてもいいんじゃないの」と思うタイミングではなく,「処理系によって,確実に GC しても良さそうだ」,と理解したタイミングで GC されます.なので,運 (*1) とかが絡みます.

まぁ,そういう原理原則のを踏まえて,手元でやってみたところ,Ruby の開発版(ruby 2.0.0dev (2012-06-20 trunk 36148) [i386-mswin32_100])では,ちゃんと sleep の前に GC されました.

で,この例は,Shu さんは消えると不味い,と仰っていますが,このタイミングでは外からアクセスする方法はないので(たとえば,ローカル変数に代入している場合は参照される可能性がありますが,この場合はどこにも参照されません).kenn さんの「TOPLEVEL_BINDING と関係あるか?」という話ですが,この場合は関係ありません.多分.

*1: 運と書きましたが,厳密には OS やらコンパイラやらの実装などが絡みます.あと,もちろん Ruby のバージョンも大いに関係します.その日の運にも依存する場合がありますので,星占いなども参考になるかもしれません.

こんなわけで,オブジェクトが GC されるタイミングは運によってしまうので,オブジェクトの後始末を特定の箇所でしたいときは,ファイナライザなどに頼らず,きちんと後始末処理を ensure 節などで書くことをお勧めします.

一般的に,Ruby の GC では「人間が見て GC されてもいいんじゃないの」と思うタイミングではなく,「処理系によって,確実に GC しても良さそうだ」,と理解したタイミングで GC されます.なので,運 (*1) とかが絡みます.

まぁ,そういう原理原則のを踏まえて,手元でやってみたところ,Ruby の開発版(ruby 2.0.0dev (2012-06-20 trunk 36148) [i386-mswin32_100])では,ちゃんと sleep の前に GC されました.

で,この例は,Shu さんは消えると不味い,と仰っていますが,このタイミングでは外からアクセスする方法はないので(たとえば,ローカル変数に代入している場合は参照される可能性がありますが,この場合はどこにも参照されません).kenn さんの「TOPLEVEL_BINDING と関係あるか?」という話ですが,この場合は関係ありません.多分.

*1: 運と書きましたが,厳密には OS やらコンパイラやらの実装などが絡みます.あと,もちろん Ruby のバージョンも大いに関係します.その日の運にも依存する場合がありますので,星占いなども参考になるかもしれません.

こんなわけで,オブジェクトが GC されるタイミングは運によってしまうので,オブジェクトの後始末を特定の箇所でしたいときは,ファイナライザなどに頼らず,きちんと後始末処理を ensure 節などで書くことをお勧めします.