D6: Possible bug in BlockClosure>>= and missing BlockClosure>>hash

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
1 message Options
Reply | Threaded
Open this post in threaded view
|

D6: Possible bug in BlockClosure>>= and missing BlockClosure>>hash

Bernhard Kohlhaas-6
Hi all,

When I recently played around a little to implement a method to provide
synchronized execution of a block, I used a shared dictionary with the
block as a key and a corresponding Mutex as a value. Soon I found that I
couldn't check for block identity, because blocks that aren't clean
apparently create a new execution context and thus a new identity every
time. However the #= method didn't work either for my purposes and I
noticed two issues there:

In a workspace evaluating
   [ Mutex ] = [ Class ]
answers true (which I don't find convincing),
while
   [ Mutex ] hash = [ Class ] hash
answers false (which is inconsistent to the previous evaluation).

I'm wondering, if the first issue could be correctly resolved by also
comparing the initialIP in the #= method, so two blocks in the same
method can be distinguished, i.e (with an extra identity check prepended):

   BlockClosure>>= aBlockClosure
    ^self == aBlockClosure or: [
       aBlockClosure class == self class and:
         [method = aBlockClosure method and:
           [initialIP = aBlockClosure initialIP and:
            [outer = aBlockClosure outer and:
              [self size = aBlockClosure size and:
                [(1 to: self size) allSatisfy:
                  [:i | (self at: i) = (aBlockClosure at: i)]]]]]]]


To resolve the 2nd issue, the class needs a #hash method, perhaps
something like this (assuming the implementation of BlockClosure>>= from
above):
   BlockClosure>>hash
        ^(1 to: self size)
                inject: method hash + initialIP hash + outer hash
                into: [:sum :i | sum + (self at: i) hash]

For my little project though even the new #= method isn't really
appropriate, since for my purpose I probably only want to compare the
position in the code for "sameness", which would mean comparing the
instance vars "method" and "initialIP". So I'll start playing with
SearchPolicies next.

Bernhard