On 12 October 2011 23:22, Levente Uzonyi <[email protected]> wrote: > On Wed, 12 Oct 2011, Mariano Martinez Peck wrote: > >> On Wed, Oct 12, 2011 at 5:38 PM, Levente Uzonyi <[email protected]> wrote: >> >>> On Wed, 12 Oct 2011, Clara Allende wrote: >>> >>> Hi guys, >>>> >>>> I'm wondering, why? >>>> >>>> ProtoObject>> ~~ anObject >>>> "Answer whether the receiver and the argument are not the same object >>>> (do not have the same object pointer)." >>>> >>>> self == anObject >>>> ifTrue: [^ false] >>>> ifFalse: [^ true] >>>> >>>> >> Hi Carla. I can think about two things. The first one, is the one Levente >> said, performance. >> If you analyze the bycode of this method, you will see that it is >> extremely >> fast because: >> >> 1) #== has an special associated bytecode, that is, them VM maps such >> bytecode to an specific primitive and it is directly executed. It means >> that >> the method #== is really never sent. >> 2) ifTrue:ifFalse: is also optimized (inlined) by the compiler. Again, it >> method is never executed and instead the compiler replace a message send >> bytecode with jump ones. >> >> Another possible reason (it may not be the case, but in another places it >> is), is to prevent VM interruption for check other processes. In summary, >> the VM checks whether it should execute another process of the queue after >> a >> method execution. As you know, some parts of the scheduling process is >> done >> at the image side. And from there we lack a way to say to the VM, "please >> execute this method without checking others processes". Hence, in a few >> yet >> very specific places of PRocess, Scheduler, Semaphore, etc, #== is used as >> a >> mean of executing something WITHOUT being interrupted. I can imagine that >> it >> may happen the same with #~~. So if you implement such method with a #not, >> you will indeed send a message, proving a possibilty to be interrupted. > > I don't see how this would be a reason. When you send #~~, then you > explicitly allow a suspension point, so not using #not won't avoid > suspension points. >
To my thinking, in a first place, i would ask: why instead of fixing the code which may be affected by having or not suspension points, we introducing new workarounds ?? I think it is bad excuse for introduction of new primitive. If we miss some atomicity for semaphores, lets add a primitive(s) which fixing the semaphore issue(s). But introducing new primitive to avoid suspension?!?! i cannot follow this line of thinking. >> >> Another reasons, similar to the previous one, is that sometimes #== is >> also >> used as a way to avoid executing method. So..there are some methods (I >> don't >> remember if #allInstancesDo: or #allObjectsDo:) will loop forever because > > #allInstancesDo: uses primitives to avoid the problem. #allObjectsDo: uses a > custom marker object, so creating new objects won't cause infinite loop > (because gc doesn't change the order of any two objects). > >> the loop condition would be creating objects (remember that method >> execution >> creates objects such as MethodContext). > > Contexts object are not created until requested and these loops don't need > contexts. Some old methods interating through all/some objects use 0 as the > marker object. These may have problems with objects created during their > loops. > > > Levente > -- Best regards, Igor Stasenko.
