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.

Reply via email to