[ruby-core:41902] [ruby-trunk - Feature #5543] rb_thread_blocking_region() API is poorly designed

Issue #5543 has been updated by Mike Dalessio.



Another issue with the current design is that it does not support
callback-oriented APIs.

First, a counter-example. The current API perfectly supports the
following pattern:

  1) unlock GVL
  2) perform an expensive (or blocking) operation
  3) re-lock the GVL when ready to re-enter RubyLand

For example:

  /* calling pattern that is supported by the current API */

  VALUE time_consuming_thing(void *data)
  {
    /* ... something expensive ... */
  }

  /* native extension Ruby method */
  static VALUE get_it_for_me(VALUE self, VALUE foo)
  {
    rb_thread_blocking_region(time_consuming_thing, 0, RUBY_UBF_IO, 0):
  }

*But* if I am calling an event-oriented API (for example, an
subscribable database that invokes a callback when new records are
added), then I am stuck. An example of what I want to do:

  static int read_callback(VALUE self, Event *event) {
    rb_thread_blocking_region_end();
    rb_funcall(callable, "callback", convert_to_ruby(event));
    rb_thread_blocking_region_begin();
  }

  /* native extension Ruby method */
  VALUE stream_events(VALUE self)
  {
    rb_thread_blocking_region_begin();
    db->read(read_callback, self); /* this call may block for minutes, and may call read_callback multiple times */
    rb_thread_blocking_region_end();
  }

It appears that the current implementation (1.9.3) of
rb_thread_blocking_region_begin() and _end() does in fact support this
calling style, but they are not global symbols, and so I cannot call
them from my C extension.

----------------------------------------
Feature #5543: rb_thread_blocking_region() API is poorly designed
https://bugs.ruby-lang.org/issues/5543

Author: Christopher Huff
Status: Open
Priority: Normal
Assignee: 
Category: 
Target version: 


First, rb_thread_blocking_region() requires the blocking code to be pulled out into a separate function, scattering code through the source file and giving the coder more work to do to pass information through to that function. Something like rb_thread_blocking_region_begin() and rb_thread_blocking_region_end(), or the BLOCKING_REGION macro used to implement rb_thread_blocking_region(), would be far more convenient to use, but were apparently deprecated and are now only usable within thread.c.

Worse, the function passed to rb_thread_blocking_region() must return a Ruby VALUE, but also must execute without a VM lock. It is rather nonsensical to specify that a function return a Ruby object while forbidding it from accessing most of Ruby. It is likely the function won't touch the anything related to Ruby at all, and while you can use casting to work around it, you shouldn't have to. The main result of all this is less readable and even somewhat misleading code.


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