[ruby-core:24861] Re: embedding ruby 1.9 frustration

I don't know exactly what's wrong in your approach but AFAIK when
embeding ruby you can call function from Ruby API only from the same
thread where ruby interpreter was initialized and run. If you want to
syncronize or communicate with other threads you probably must use
some none rubyish functions and structures.

On Mon, Aug 10, 2009 at 9:22 PM, Rolando Abarca<[e-mail]> wrote:
> Hello,
> I've been struggling for a long time now, reading the sources,
> documentation and mostly README.ext (which seems a bit out of date).
> Anyway, I'm having some problems that so far have no answer. I'm using
> svn trunk, trying to embed a ruby1.9 interpreter into a C application.
> If the application follows a simple "one line" path, everything works
> just fine, but if the C app calls some ruby code, and the calling was
> triggered by an interrupt (an event, like a click, timer, etc), things
> can go wrong, most of the time with a bad access exception right here:
>
>
> #file vm_method.c; Line 250
> NODE *
> rb_get_method_body(VALUE klass, ID id, ID *idp)
> {
>    NODE *volatile fbody, *body;
>    NODE *method;
>
>    if ((fbody = search_method(klass, id, 0)) == 0 || !fbody->nd_body) {
> ...
>
> The exception is raised always on the if.
> The backtrace is usually like this:
>
> #0  0x00179714 in rb_get_method_body (klass=22988952, id=366, idp=0x0)
> at vm_method.c:256
> #1  0x001798b3 in rb_method_node (klass=22988952, id=366) at vm_method.c:301
> #2  0x0017ab2b in rb_method_basic_definition_p (klass=22988952,
> id=366) at vm_method.c:1057
> #3  0x0017ab83 in rb_obj_respond_to (obj=22988980, id=15424, priv=0)
> at vm_method.c:1068
> #4  0x0017ac34 in rb_respond_to (obj=22988980, id=15424) at vm_method.c:1084
> #5  0x000155f1 in sc_funcall (args=0x10f7ad0) at
> /Users/rolando/Documents/GFF/ShinyCocos/Integration/SC_init.m:74
> #6  0x000609f7 in rb_protect (proc=0x155cb <sc_funcall>,
> data=17791696, state=0xbfffe53c) at
> /Users/rolando/Documents/GFF/ShinyCocos/ruby/eval.c:648
> #7  0x00015726 in sc_protect_funcall (recv=22988980, mid=15424, n=1)
> at /Users/rolando/Documents/GFF/ShinyCocos/Integration/SC_init.m:105
>
> Regarding the ruby interpreter, this is what I'm doing to initialize/start it:
>
>        sc_argc = 2;
>        sc_argv = (char **)malloc(sizeof(char *) * 2);
>        sc_argv[0] = "ShinyCocos";
>        sc_argv[1] = (char *)[entryPoint cStringUsingEncoding:NSUTF8StringEncoding];
>
>        ruby_sysinit(&sc_argc, &sc_argv);
>        {
>        RUBY_INIT_STACK;
>        ruby_init();
>        }
>        ...
>        ruby_script("main.rb");
>        rb_protect(RUBY_METHOD_FUNC(rb_require), (VALUE)"main", &state);
>
> main.rb has code in it: starts the Cocos2D-iphone framework (something
> like gosu)
> And to call the ruby world from a C callback (which is triggered by
> the framework), This is what I'm doing:
>
>        struct rb_blocking_region_buffer *region = rb_thread_blocking_region_begin();
>        sc_protect_funcall((VALUE)userData, id_sc_on_enter, 0, 0);
>        rb_thread_blocking_region_end(region);
>
> sc_protect_funcall is just like rb_funcall, but the call is rb_protected.
> What I'm not doing, but I think I should (just don't know where to put
> it) is a call to ruby_run.
>
> I'm getting really frustrated, because there's almost no documentation
> on how to embed ruby 1.9, and how to treat code that might call the VM
> on an async way (some calls to rb_funcall might be called when there's
> already some ruby code running, I'm thinking that might be the problem
> here). I thought that adding rb_thread_blocking_region_begin/end() was
> the solution, but I'm still getting random crashes...
> Any pointer on how to do it The Right Way(tm)?
>
> Thanks a lot,
> --
> Rolando Abarca
> http://rolando.cl
>
>



-- 
Pozdrawiam

Radosław Bułat
http://radarek.jogger.pl - mój blog