[ruby-core:37132] Re: [Ruby 1.9-Feature#4328][Open] export rb_thread_call_with_gvl()

Hi,

(2011/06/14 14:56), Eric Wong wrote:
> I think the assumptions and requirements for calling this function are
> reasonable (and best of all, well-documented).  The API isn't difficult
> to me and the documentation is clear as to what is safe and what is not.
> 
> Threading APIs can always be tricky, but I think the C API for GVL is
> a good one.

I think a requirement "caller should be a Ruby thread" is difficult.

For example, external library calls registered callback in other native
threads (not ruby threads).  If C extension programmer does not know
such specification of external library, (s)he would make and register a
callback function using this API.  Finally, the Ruby code run on non
Ruby code.  I'm afraid of such situation.

To avoid this situation, one solution is checking "the thread is really
Ruby thread or not" when rb_thread_call_with_gvl() is called.  This
check was already introduced into this API.

Other solution is making the non-ruby thread to ruby thread.  I feel
necessity of such API, however, I need more consideration to implement it.

To limit to usage of rb_thread_call_with_gvl() as "only blocking
function", former (current) solution is enough.


>> BTW, the naming "_with_gvl" is reasonable for native English speakers?
> 
> Yes.

Thank you.  We keep this name.

Please discuss with me about naming of another "_with_gvl".
In gc.c, there are other "_with_gvl" functions.

- negative_size_allocation_error_with_gvl
- gc_with_gvl

The functions are callback of rb_thread_call_with_gvl().

The meaning of "with_gvl" in rb_thread_call_with_gvl() is "acquire GVL
and call passed function".  However, above two functions use then name
"*_with_gvl" in different meaning (run in GVL acquired situation, only).

Do you have good naming idea for them?

-- 
// SASADA Koichi at atdot dot net