[
https://issues.apache.org/jira/browse/PROTON-752?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14224422#comment-14224422
]
Dominic Evans commented on PROTON-752:
--------------------------------------
So I can see that this might be a useful thing to add to the gem, as it does
allow a user to trivially pass an event loop-style block to a messenger and to
have it all executing asynchronously in a separate Thread. However, in your
example of passing in a pre-created messenger object and/or returning the
messenger object from the receive_and_call method, there is no locking around
the messenger object? Messenger isn't thread-safe itself, so with ruby's Thread
wakeup semantics it would be quite easy to start hitting race conditions when
you allow the user to interact with messenger on multiple Threads in this way.
So I think there is more work to do here to make this a robust feature.
However, I still think that this patch is really about adding a new method that
exposes the 'passive messenger' functionality in an easily-consumable way,
which sounds like a useful thing to have but it doesn't seem to address this
JIRA issue which is specifically: "As a Ruby >=1.9.x user, I expect to be able
to call Messenger's blocking calls in a way that blocks my current Thread until
the call I/O completes, but doesn't lock all Ruby Threads in the process".
> 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)
