Hi Dave, interesting stuff. Apparently you can tell the GC not to mess with your stuff using rb_gc_register_address (and rb_gc_unregister_address when/if you're done).
Looking at gc.c, all it does is add the pointer to the GC's list of things that are being used, so it won't free it. an example from the Ruby source (showing it being used before object creation): ext/iconv/iconv.c rb_gc_register_address(&charset_map); charset_map = rb_hash_new(); rb_define_singleton_method(rb_cIconv, "charset_map", charset_map_get, 0); I guess you can register before filling the array, set the length, then unregister. Not sure if this actually locks all the values in the array though :/ If not, perhaps you could overwrite the mark function for the array and restore it afterwards, heh. Perhaps not worth the fiddling. I'm no Ruby extension expert though, so beware :) John. -- http://johnleach.co.uk On Fri, 2007-02-23 at 17:11 +1100, David Balmain wrote: > On 2/22/07, John Leach <[EMAIL PROTECTED]> wrote: > > Thanks Dave! Looking forward to it. > > > > Can you tell us a bit more about what led to the segfault error cropping > > up? Have they been in the 0.10 branch all along? 0.9 too? Or did some > > new work break something? > > > > Maybe it will help others debug problems in future. > > Well, the main problem I fixed was due to an error introduced in 0.10. > I wasn't locking the commit log in all the places I should have. This > actually would have been very easy to fix if someone had supplied a > repeatable test case. In the end though I decided to lock-less > commits, a new feature that has recently been added to Lucene. The > main advantages of this are that you can open IndexReaders when an > IndexWriter is committing and you can open multiple IndexReaders at a > time without them interrupting each other. It also makes it much > easier to recover after a crash. If your system crashes in the middle > of a commit then Ferret will be able to open the previously committed > version of the index. <snip> _______________________________________________ Ferret-talk mailing list [email protected] http://rubyforge.org/mailman/listinfo/ferret-talk
