Christopher Huff <cjameshuff / gmail.com> wrote:
> 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.

rb_thread_blocking_region_begin() and rb_thread_blocking_region_end()
require malloc()/free(), so there may be a performance impact there
for some code.

The BLOCKING_REGION macros make it too easy to break ABI compatibility
and require users to rebuild 3rd-party libraries.  ABI compatibility is
apparently an important thing for users on crippled OSes that don't
include free compilers :<

> 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.

No return type can possibly satisfy everyone who will use this function,
VALUE is probably the least bad since the object the VALUE refers to
could be created before entering the blocking region.


I had no hand/influence in the design of this API, but I feel it's the
best API given the circumstances (need for a GVL + compatibility).