[
https://issues.apache.org/jira/browse/ZOOKEEPER-661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12828709#action_12828709
]
Andrew Reynhout commented on ZOOKEEPER-661:
-------------------------------------------
Hi Patrick,
The threading trickiness is similar to Python's: no true native threads, and a
big Global Interpreter Lock (Ruby calls it the GVL). Unlike Python, Ruby's
mechanisms exposed for external synchronization are (appear to be) awkward and
very sparsely documented. I'm no expert on Ruby internals either, but I spent
some time trolling through the 1.8 and 1.9 source trees to find a way to make
this work...this is the best solution I could come up with.
Your point about the ZK ST vs MT libraries is interesting. I considered that
approach at one point, but abandoned it because I thought it wouldn't work for
watchers. I don't remember what made me think that -- I've been working on
this very sporadically for a while. If I'm following the concept, I would just
manage all of the threading within Ruby and let the async calls (and watchers)
wait in Ruby threads for the libzookeeper_st function to return..?
I'll take a look at that and see what I can learn. Thank you for the pointers.
> Add Ruby bindings
> -----------------
>
> Key: ZOOKEEPER-661
> URL: https://issues.apache.org/jira/browse/ZOOKEEPER-661
> Project: Zookeeper
> Issue Type: New Feature
> Components: contrib-bindings
> Environment: MRI Ruby 1.9
> JRuby 1.4
> Reporter: Andrew Reynhout
> Priority: Minor
>
> Add Ruby bindings to the ZooKeeper distribution.
> Ruby presents special threading difficulties for asynchronous ZK calls (aget,
> watchers, etc). It looks like the simplest workaround is to patch the ZK C
> API.
> Proposed approach will be described in comment.
> Please use this ticket for discussion and suggestions.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
