And if it's used like in example #1, and then there's an exception (which is rescued in user code), and then a new request is issued - would it still use Keep-Alive? Because if it will, then at least the bug can be worked-around...romanbsd (Roman Shterenzon)
I would like to say that without applying this patch, my ruby interpreter, embedded in a pthread, would cause a segmentation fault as soon as GC was invoked. I would like to see this applied to 1.9.1 as well as http://redm...romanbsd (Roman Shterenzon)
=begin Sorry for the lack of explanation, I thought that it was implicit and apparent. After I get thread's stack_begin and stack_end I'm calling your bind stack function, of course. =end romanbsd (Roman Shterenzon)
=begin I'm embedding a Ruby 1.9.1 in my app, and it would die with segmentation fault, and I was suspicious about the stack, as it's multithreaded. I applied your patch and it looks fine so far. I'm using the following code (and assume ...romanbsd (Roman Shterenzon)
=begin r21463 (originally r21441) still bothers me, as a GC which is triggered in C code of the embedding application (say rb_ary_new) will cause the application to exit with fatal error, as it's not ruby_native_thread_p(). Should I ope...romanbsd (Roman Shterenzon)
=begin The function vm_xmalloc() will call garbage_collect_with_gvl() even if dont_gc is set by rb_gc_disable(). This is ok (though wastes some CPU cycles) when the code is running in native Ruby interpreter, as later the garbage_coll...romanbsd (Roman Shterenzon)
romanbsd (Roman Shterenzon)11:41 PM Ruby Bug #6397 (Closed): Net::IMAP::ResponseParseError: unexpected token LPAR (expected QUOTED or LITERAL)