Dominic Evans commented on PROTON-752:

[~mcpierce] so I had a look at the patch, but I'm not sure adding new methods 
is necessarily the right answer here. In any case, I'm not suggesting that the 
calls should be non-blocking or run in a different Thread to the one that 
called them. The messenger calls should still be blocking (when 
messenger.blocking == true) on the Thread they were called, but they should 
unlock the Ruby GIL so that any other Ruby threads (which could be doing 
completely unrelated work) can make progress on that work in the interim. Once 
the messenger C code has run, the GIL lock will be acquired again when next 
eligible and the Thread will progress.

The exact same issue can effects any of the messenger calls, not just receive. 
If I messenger.put a number of large messages and call messenger.send it will 
keep the GIL locked unnecessarily and prevent anything else in my Ruby app from 
making progress until that I/O has completed.

RE: 1.8,  I don't think you need to worry about this in the Ruby 1.8 case, as 
everything there is mapped onto a single operating-system thread so unlocking 
the GIL wouldn't reap any benefits (and hence why the method calls to unlock it 
weren't available).

> Ruby: Cproton calls don't unlock the GIL for blocking / long-running 
> operations
> -------------------------------------------------------------------------------
>                 Key: PROTON-752
>                 URL: https://issues.apache.org/jira/browse/PROTON-752
>             Project: Qpid Proton
>          Issue Type: Bug
>          Components: ruby-binding
>    Affects Versions: 0.8
>            Reporter: Dominic Evans
>            Assignee: Darryl L. Pierce
>            Priority: Minor
>         Attachments: 
> 0001-PROTON-752-Provide-a-non-blocking-means-to-receive-m.patch
> Currently the I/O-style calls to the Cproton methods don't unlock the Ruby 
> GIL, impacting performance as other Threads could be given time on the 
> interpreter whilst the extension code is running. 
> Depending on Ruby version this is simply a matter of wrapping the calls in 
> rb_thread_call_without_gvl (Ruby 2.x +) or rb_thread_blocking_region (Ruby 
> 1.9.x). On Ruby 1.8 I'm not sure if you can enable this, but its my 
> understanding that RHEL requires continued support for 1.8, so some #define 
> work would be needed to perform a no-op on that version.

This message was sent by Atlassian JIRA

Reply via email to