From: SASADA Koichi Date: 2012-07-21T05:17:14+09:00 Subject: [ruby-core:46578] Re: [ruby-trunk - Feature #6762] Control interrupt timing (2012/07/21 4:48), Eric Wong wrote: > "ko1 (Koichi Sasada)" wrote: >> * Un-safe ensure clause: Generally, ensure clause should not interrupt >> because it contains important tasks such as freeing resources. > > Thank you for addressing this issue. ensure clause behaving properly > is most important to me. > >> # example: Guard from Thread#raise >> th = Thread.new do >> Thead.control_interrupt(RuntimeError => :never) { >> begin >> # Thread#raise doesn't interrupt here. >> # You can write resource allocation code safely. >> Thread.control_interrupt(RuntimeError => :immediate) { >> # ... >> # It is possible to be interrupted by Thread#raise. >> } >> ensure >> # Thread#raise doesn't interrupt here. >> # You can write resource dealocation code safely. >> end >> } >> end > > I like the above is now possible and safe, but I think having > Thread.control_interrupt twice in above example is repetitive > and error-prone. > > How about having something like at_exit, but local to the current scope: I understand what you want. In my ticket, I proposed two things. (1) Introducing the concept to "interrupt control" (2) Introducing primitives to achieve (1) Maybe you proposed (3) Extra APIs to use (1) and (2) in easy way (or (2)?) I want to make clear and fix the (1) and (2) before (3). How about it? ---- > How about having something like at_exit, but local to the current scope: > > def something > at_scope_exit do > # Thread#raise doesn't interrupt here. > # do what you would normally do in ensure clause > # deallocate resource if allocated > res.release if res > end > > # It is possible to be interrupted by Thread#raise. > # You can write resource allocation code safely because > # at_scope_exit already registered deallocation code > res = Foo.acquire > ... > > end > > at_scope_exit could probably take the same args as > Thread.control_interrupt, too: > > at_scope_exit(TimeoutError => :never) { ... } We need more extra primitive to hook block ending to implement it. It seems hard task... A Trivial point. `res' in block is not a variable (it parsed as method) because the assignment of res (res = ...) is placed after the block. One idea is extending ensure semantics. I'm not sure how to design it.... We need more ideas. -- // SASADA Koichi at atdot dot net