Laurent Sansonetti
lsans****@apple*****
Wed Jun 7 00:42:36 JST 2006
On Jun 5, 2006, at 11:27 PM, Jonathan Paisley wrote:
>
> On 31 May 2006, at 17:30, Laurent Sansonetti wrote:
>
>> - Changed the internal ObjC-to-Ruby cache from CFDictionary to Ruby's
>> bundled st.h, that should be quicker. This cache is used when
>> creating new Ruby proxies from existing Objective-C objects, to avoid
>> duplications.
>
> Was the CFDictionary cache a previous iteration of your code?
>
Yes, I wrote a first iteration using CFDictionary, just for sample
purposes. Then I realized I could use the Ruby-bundled hash
implementation, so here I went.
> I was a bit confused for a while since I had implemented a similar
> scheme using st.h for ensuring that RBObjects are unique for each
> ruby object (I'd made the bottleneck in RBObject.m). I think your
> scheme makes more sense though.
>
Oh, I did not know that. Apparently the code did not enter CVS?
> I was looking at the code in ocdata_conv.m which hands the cache
> update. Since using Ruby with NSThreads is unsafe at the moment,
> are you just future-proofing for the day that it might work?
>
Yes it's just to be sure we protect accesses to that static variable.
I guess that using the green threads would not hurt, but what if Ruby
is compiled with --enable-pthread and that 2 Ruby threads are trying
to map the same thing at the same time?
> Supposing that multiple threads do work, there's a race condition
> where two threads converting the same ruby object to objc could
> yield different objc objects. One solution would be to do another
> lookup just before the 'st_insert' and discard the new object if
> there's now a valid object in the cache.
>
You're absolutely right, initially both the lookup + insert where
"atomized" in a single lock, then I had to separately lock the
operations to avoid deadlocks, as the object creation routine is
susceptible to call itself.
I added another lookup as you suggested, thanks!
> One final thing on this: the names of the two caches ('rb2oc' and
> 'oc2rb') seem to be reversed to me. Currently, the 'rb2oc' cache
> maps from id -> VALUE, whereas the name 'rb2oc' suggests mapping
> from Ruby -> ObjC and therefore VALUE -> id. What do you think?
You're also right, I was probably drunk when I named these variables :)
I just renamed them.
Thanks for the valuable feedback,
Laurent