On Thu, 13 Oct 2011, Igor Stasenko wrote:

On 12 October 2011 23:22, Levente Uzonyi <[hidden email]> wrote:

On Wed, 12 Oct 2011, Mariano Martinez Peck wrote:

On Wed, Oct 12, 2011 at 5:38 PM, Levente Uzonyi <[hidden email]> 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 ??

Which code needs to be fixed?

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

Are there any issues with semaphores?

But introducing new primitive to avoid suspension?!?!  i cannot follow
this line of thinking.

I guess you're not replying to my mail, but Eliot's. Btw there's no such "line of thinking". He didn't add the primitive for #~~ to avoid a suspension point, but to improve it's performance.

Levente

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.