Hi
We are looking at upgrading our current version of ruby 1.8.7 to latest
1.9.2-p0, We have been running ruby embedded within a pthread with a
swigged up interface for about 7 years and it has worked fine. On
changing to 1.9 we get a crash on initialistaiion the first time the gc
is called.
This occurs in mark_current_machine_context
Under 1.8.7 we initialised the ruby thread thus
int ScriptThread::run()
{
int addr;
ruby_init();
Init_stack((void *)&addr);
ruby_script(“embedded”);
ruby_init_loadpath();
Init_gm(); // swigged up interface
…
}
Under 1.9 I changed this to:
RUBY_GLOBAL_SETUP
int ScriptThread::run()
{
//ruby_sysinit(&argc, &argv); // commented out, no args
available
{
RUBY_INIT_STACK;
ruby_init();
}
Init_gm();
…
}
Note that our thread is created thru QT using pthreads. We also compile
1.8.7 without pthread support. Our interpreter runs exclusively in this
thread and all VALUE’s created in C are properly wrapped and marked.
I have read the threads from
http://www.ruby-forum.com/topic/144747
http://redmine.ruby-lang.org/issues/show/2294
From these it would appear that
a) The ruby initialisation must be done in main
Is this a change from 1.8.7? What if we are dynamically loaded and have
no access to main?
b) The thread should be created using rb_thread_create
Is this true? If so, why?
c) disabling pthread support when compiling ruby has been deprecated.
What does this mean? - Does ruby use threads itself?
I briefly tried to disable the gc and then got a crash
d) Should we apply the patch from 2294?
What is the correct way to do this?
I would greatly appreciate any help anyone could give.
On Tue, Nov 16, 2010 at 11:24 AM, Steve H. [email protected] wrote:
int ScriptThread::run()
Under 1.9 I changed this to:
}
Init_gm();
…
}
Note that our thread is created thru QT using pthreads. We also compile
1.8.7 without pthread support. Our interpreter runs exclusively in this
thread and all VALUE’s created in C are properly wrapped and marked.
This is no longer true with 1.9. 1.9 uses native threads (although
there’s still the GIL which slows it somewhat down). I do not know
how best to interact but I guess you could find hints by looking at
thread creation code.
c) disabling pthread support when compiling ruby has been deprecated.
What does this mean? - Does ruby use threads itself?
See above.
I briefly tried to disable the gc and then got a crash
d) Should we apply the patch from 2294?
What is the correct way to do this?
I would greatly appreciate any help anyone could give.
Others can certainly give more detailed advice but my quick heads up
might send you in the right direction.
Kind regards
robert
On Tue, Nov 16, 2010 at 12:24 PM, Steve H. [email protected] wrote:
a) The ruby initialisation must be done in main
Is this a change from 1.8.7? What if we are dynamically loaded and have
no access to main?
b) The thread should be created using rb_thread_create
Is this true? If so, why?
c) disabling pthread support when compiling ruby has been deprecated.
What does this mean? - Does ruby use threads itself?
I briefly tried to disable the gc and then got a crash
d) Should we apply the patch from 2294?
Unfortunately, I never found a solution. In my situation the problem
was exacerbated by the fact that the main program loaded each plug-in
into it’s own thread. FWIW, I ended up, due to timing constraints,
converting the dynamic module into an “agent” that communicated with a
separate process, a ruby server written in ruby. Not for every
situation, pretty, or efficient, but it bought me some time.
When I tired the patch in 2294, it delayed the crash but didn’t
eliminate it. I see that Suraj has made a few updates since I last
tried it. It is worth a try since it worked for some people. I hope to
try the latest patch soon and update the issue with my findings.
Regards,
Ammar