From: Charles O Nutter Date: 2006-08-16T23:36:40+09:00 Subject: Re: sandbox timers & block scopes ------=_Part_142261_7867623.1155738999048 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 8/16/06, Francis Cianfrocca wrote: > > I'm not sure if I'm about to repeat what Charles has already said, but > how about you add a structure inside the interpreter loop that gets a > value added to it whenever a timed sandbox starts up (and removed > whenever it completes)? There can be multiple sandbox timeouts active > at a time, so you can do this from multiple green threads. The > structure contains the real time at which each timeout expires, and > the associated thread descriptor. Add something to the interpreter > loop that runs down the expired timeouts every time through, and > raises a Ruby exception to each expiring sandbox. It's heavyweight > because of the kernel-lock needed to check the time but maybe Ruby is > already doing that somewhere else. This is basically the same, yes...but I think we're both on the right track. There are already hooks in the interpreter "loop" to check whether a thread context switch has been requested, and the sandbox is really just a special case of green threads. Overloading that feature to monitor sandbox runtime--especially if per-sandbox threading is disabled for such scenarios--should be very easy to do (and it works across platforms, of course, since the threading-signaling code is already there). -- Contribute to RubySpec! @ www.headius.com/rubyspec Charles Oliver Nutter @ headius.blogspot.com Ruby User @ ruby.mn JRuby Developer @ www.jruby.org Application Architect @ www.ventera.com ------=_Part_142261_7867623.1155738999048--