From: Roman Shterenzon <romanbsd@...>
Date: 2009-10-24T21:38:28+09:00
Subject: [ruby-core:26274] Re: Ruby 1.9.1 embedding and GC

It obviously does.
What happens, is the following, when some object (in my case an array) is to be allocated, the vm_xmalloc is called.
(The GC should be off, as I called gc_disable, remember).
Then, in vm_xmalloc there a condition (malloc_increase+size) > malloc_limit) which holds true, and then garbage_collect_with_gvl(objspace) is called (though the GC was disabled.. the check for this is postponed).
The garbage_collect_with_gvl check if it's a ruby native thread (ruby_native_thread_p()) and if it's not - bails out with exit. I believe that this is a reasonable thing, when the main program is the ruby interpreter, but it's probably wrong for an embedded interpreter. So either I need to run my code in "native ruby thread", but I didn't quite understand yet from reading the code how to do that and if it's feasible. On the other hand, if I change the vm_xmalloc to check the dont_gc earlier, there still will be a problem if the GC is NOT disabled, and it'll follow the same path.

--Roman



----- Original Message ----
From: Roger Pack <rogerdpack@gmail.com>
To: ruby-core@ruby-lang.org
Sent: Fri, October 23, 2009 11:12:49 PM
Subject: [ruby-core:26261] Re: Ruby 1.9.1 embedding and GC

> My code:
> -----
> RUBY_INIT_STACK;
> ruby_init();
> ruby_init_loadpath();
> ruby_script(service_file);
> rb_define_module("Gem");
> rb_gc_disable();

I'd add an output to garbage_collect so you can see if it *is* GC'ing
[which apparently it is?]  if so then try to see why.
GL.
-r