[ 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.