[
https://issues.apache.org/jira/browse/PROTON-752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14223514#comment-14223514
]
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
(v6.3.4#6332)
