[#8484] strptime fails to properly parse certain inputs — <noreply@...>

Bugs item #5263, was opened at 2006-08-01 23:14

13 messages 2006/08/02
[#8485] Re: [ ruby-Bugs-5263 ] strptime fails to properly parse certain inputs — Yukihiro Matsumoto <matz@...> 2006/08/02

Hi,

[#8538] Re: [ ruby-Bugs-5263 ] strptime fails to properly parse certain inputs — nobu@... 2006/08/06

Hi,

[#8561] sandbox timers & block scopes — why the lucky stiff <ruby-core@...>

Two puzzles I am trying to solve:

28 messages 2006/08/08
[#8624] Re: sandbox timers & block scopes — why the lucky stiff <ruby-core@...> 2006/08/15

raise ThisDecayingInquisition, "anyone? anyone at all?"

[#8627] Re: sandbox timers & block scopes — MenTaLguY <mental@...> 2006/08/15

On Wed, 2006-08-16 at 00:35 +0900, why the lucky stiff wrote:

[#8628] Re: sandbox timers & block scopes — why the lucky stiff <ruby-core@...> 2006/08/15

On Wed, Aug 16, 2006 at 02:46:30AM +0900, MenTaLguY wrote:

[#8629] Re: sandbox timers & block scopes — "Charles O Nutter" <headius@...> 2006/08/15

On 8/15/06, why the lucky stiff <ruby-core@whytheluckystiff.net> wrote:

[#8690] a ruby-core primer — why the lucky stiff <ruby-core@...>

Hello, all. I've been working on the ruby-core page for the new Ruby site.

21 messages 2006/08/22

Re: sandbox timers & block scopes

From: "Charles O Nutter" <headius@...>
Date: 2006-08-15 19:05:20 UTC
List: ruby-core #8629
On 8/15/06, why the lucky stiff <ruby-core@whytheluckystiff.net> wrote:
>
> On Wed, Aug 16, 2006 at 02:46:30AM +0900, MenTaLguY wrote:
> > Having a watchdog thread should require the least hackery -- maybe the
> > only question at that point is whether it's easy for a separate thread
> > to cleanly kill a rogue sandbox the way you want it to?
>
> Yeah, that's just it.  I don't want to kill the whole thread containing
> the
> sandbox.  Just stop the eval.  And if I can avoid using an actual Ruby
> thread to
> monitor the sandbox, I would like that!


Caveat: I'm no Ruby C expert, but I've studied the threading code pretty
closely to better ape it in JRuby.

I think it should not be difficult for you to tie into the already-existing
thread-context-switching code in Ruby. As I understand it, every 10ms a
signal is fired that triggers a variable to be set which will, on
appropriate execution boundaries, cause a thread context switch to occur.
It's mostly a cooperative switching, since the code in question must
encounter one of several nodes that do this check, but it ought to be a good
place for you to hook in your timer and forcibly switch sandboxes.

Bringing up my Ruby 1.8 source, I believe the macro you're looking for is:

# define CHECK_INTS do {\
    if (!(rb_prohibit_interrupt || rb_thread_critical)) {\
        if (rb_thread_pending) rb_thread_schedule();\
    if (rb_trap_pending) rb_trap_exec();\
    }\
} while (0)

When the 10ms signal fires, rb_thread_pending is set to 1, causing this
macro (called at various places in the interpreter cycle) to invoke the
thread scheduler. It shouldn't be hard to add in your sandbox
timeout/sandbox switch code the same way.

The only caveat I can see is that the 10ms signal is only started up once
there's more than a single green thread. You'd probably need to forcibly
start it once another sandbox is initialized.

-- 
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

In This Thread