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

Issue #5543 has been updated by Koichi Sasada.

Assignee set to Koichi Sasada
Target version set to 2.0.0

Christopher Huff wrote:
> VALUE is actively misleading, given that a VALUE can not be constructed by the function, and the writer of the code will most likely not want to return a pre-constructed one. "void *" is the obvious choice, not carrying such an implication and making it clear that greater care is necessary when using the function...in particular, making it clear that what it returns can't be assumed to be a valid VALUE. If we're going to be stuck with an awkward API that forces us to spin off little side functions and cram data through a single input pointer and single return pointer, we should at least not have to deal with an API that lies to us.

Should we change it from VALUE to 'void *'?
It's not big compatibility issue, I think (maybe it causes several warnings at compiling time).



----------------------------------------
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: Koichi Sasada
Category: 
Target version: 2.0.0


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://bugs.ruby-lang.org/