Issue #6433 has been updated by ibc (Iñaki Baz Castillo).


ko1 (Koichi Sasada) wrote:
> (2012/05/14 21:57), ibc (Iñaki Baz Castillo) wrote:
>  > So... is ubf() called with the GVL or not??
>  
>  No.  ubf() will call *without* GVL.  I'm not sure why your code said
>  such error.  Can you show us a reproduce-able small code?

My code clearly says "[BUG] rb_thread_call_with_gvl: called by a thread which has GVL.".

You can reproduce it by downloading it (Ruby 1.9.2 or perhasp 1.9.3 required):

~# git clone git://github.com/ibc/AsyncEngine.git
~# cd AsyncEngine/
~# rake (it should success)
~# cd test/others/

~# ruby crash_ubf_with_gvl.rb

C DBG: run_uv_without_gvl() starts
..........C NOTICE: ae_thread_killed() starts, running rb_thread_call_with_gvl(terminate_uv_with_gvl, NULL)...
crash_ubf_with_gvl.rb:15: [BUG] rb_thread_call_with_gvl: called by a thread which has GVL.
ruby 1.9.2p0 (2010-08-18 revision 29036) [x86_64-linux]

-- control frame ----------
c:0004 p:---- s:0010 b:0010 l:000009 d:000009 CFUNC  :kill
c:0003 p:0111 s:0007 b:0007 l:000f08 d:000d60 EVAL   crash_ubf_with_gvl.rb:15
c:0002 p:---- s:0004 b:0004 l:000003 d:000003 FINISH
c:0001 p:0000 s:0002 b:0002 l:000f08 d:000f08 TOP   
---------------------------
-- Ruby level backtrace information ----------------------------------------
crash_ubf_with_gvl.rb:15:in `<main>'
crash_ubf_with_gvl.rb:15:in `kill'

-- C level backtrace information -------------------------------------------
/usr/lib/libruby-1.9.1.so.1.9(rb_vm_bugreport+0x5f) [0x7fdcfff64b1f]
/usr/lib/libruby-1.9.1.so.1.9(+0x5b304) [0x7fdcffe70304]
/usr/lib/libruby-1.9.1.so.1.9(rb_bug+0xb3) [0x7fdcffe70473]
/usr/lib/libruby-1.9.1.so.1.9(rb_thread_call_with_gvl+0x160) [0x7fdcfff68680]
/tmp/kk/AsyncEngine/lib/asyncengine/asyncengine_ext.so(+0xf0f4) [0x7fdcfe8890f4]
/usr/lib/libruby-1.9.1.so.1.9(rb_threadptr_interrupt+0x3c) [0x7fdcfff659bc]
/usr/lib/libruby-1.9.1.so.1.9(rb_thread_kill+0x48) [0x7fdcfff680a8]
/usr/lib/libruby-1.9.1.so.1.9(+0x148be8) [0x7fdcfff5dbe8]
/usr/lib/libruby-1.9.1.so.1.9(+0x140dd0) [0x7fdcfff55dd0]
/usr/lib/libruby-1.9.1.so.1.9(+0x1457f1) [0x7fdcfff5a7f1]
/usr/lib/libruby-1.9.1.so.1.9(rb_iseq_eval_main+0xb2) [0x7fdcfff5aa42]
/usr/lib/libruby-1.9.1.so.1.9(+0x5e4c2) [0x7fdcffe734c2]
/usr/lib/libruby-1.9.1.so.1.9(ruby_exec_node+0x1d) [0x7fdcffe734ed]
/usr/lib/libruby-1.9.1.so.1.9(ruby_run_node+0x1e) [0x7fdcffe74dae]
ruby(main+0x4b) [0x40099b]
/lib/libc.so.6(__libc_start_main+0xfd) [0x7fdcfeff0c8d]
ruby() [0x400889]
-----------------------------------------------------------------


The main C file is ext/asyncengine/asyncengine_ruby.c.

lib/asyncengine.rb contains the method AsyncEngine.run (AE.run) which invockes AE._c_run defined in asyncengine_ruby.c. This method uses rb_thread_call_without_gvl() to start the UV loop, which blocks. When an event occurs, the Ruby callback is called with rb_thread_call_with_gvl() (this works ok). When a signal (i.e. Interrupted) is received in the thread running AE, the ubf function ae_thread_killed() is called, and that function uses rb_thread_call_with_gvl(terminate_uv_with_gvl, NULL).

The function terminate_uv_with_gvl() runs the Ruby method AE.stop, which iterates over all the existing UV handles (in a @_handles Hash) and invokes #destroy on each of them, so they are closed by UV and the C blocking function uv_run() exits.

So I need to run AE.stop from the ubf function since it's hard to clean a Hash from C (rb_hash_clear is not public). The problem is that, when the ubf function calls to rb_thread_call_with_gvl(terminate_uv_with_gvl, NULL), the above error occurs.



>  PS1: I'm surprising that you want to invoke Ruby code.  I only imagine
>  ubf() as a small code such as "toggle cancel flag" or "kick some API to
>  cancel invoking situation".  Maybe you shouldn't use Ruby code (Ruby
>  code can be run after blocking process is canceled).

uv_run() (from the C library UV) just exits when all its handles have been closed with the uv_close() function. I store the uv handles within C structures in Ruby AsyncEngine classes (i.e. AsyncEngine::Timer), so I need to iterate over all the Ruby AsyncEngine::XXXXX instances (stored in AE.@_handles) and invoke the #destroy method on them.
----------------------------------------
Bug #6433: rb_thread_blocking_region(): ubf() function is executed with GVL
https://bugs.ruby-lang.org/issues/6433#change-26623

Author: ibc (Iñaki Baz Castillo)
Status: Open
Priority: Normal
Assignee: 
Category: ext
Target version: 1.9.2
ruby -v: ruby 1.9.2p290 (2011-07-09 revision 32553) [x86_64-linux]


thread.c says:

------------------------
 *   If another thread interrupts this thread (Thread#kill, signal delivery,
 *   VM-shutdown request, and so on), `ubf()' is called (`ubf()' means
 *   "un-blocking function").  `ubf()' should interrupt `func()' execution.

 *   NOTE: You can not execute most of Ruby C API and touch Ruby
 *         objects in `func()' and `ubf()', including raising an
 *         exception, because current thread doesn't acquire GVL
 *         (cause synchronization problem).

VALUE
rb_thread_blocking_region(
   rb_blocking_function_t *func, void *data1,
   rb_unblock_function_t *ubf, void *data2)

--------------------------


I've created my ubf() function which is called when the Ruby thread in which rb_thread_blocking_region() was called is killed or interrupted. Within my ubf() function I expect not to have the GVL (as the doc says) and I need to run Ruby code, so I use:

  rb_thread_call_with_gvl(terminate_my_C_reactor_with_gvl, NULL);

and I get an error:

 [BUG] rb_thread_call_with_gvl: called by a thread which has GVL.

So... is ubf() called with the GVL or not??


-- 
http://bugs.ruby-lang.org/