Hi guys. We were discussing yesterday with Marcus about the following....<br><br> I remember a problem we have in Pharo because of changing "foo == nil" to "foo isNil" in some important places like Process/Delay/Semaphore. Such change introduces a suspension point, where if I understand correctly, the scheduler can switch to another process only during method sends. #== is optimized with a special bytecode and there is no message send. Sending #isNil is a message sent, and hence we introduce a suspension point. In 99% of the cases this is not a problem. But I can imagine that there are places (mostly those related to Process/Delay/Semaphore) where this changes can be very very bad. <br>
<br> <br>To do some experiments, I want to remove the bytecode for #== but of course, I think I will have all these problems. And there are more. Marcus told me that some optimizations done by the compiler end up sending #==. And I also remember some code he told me (I think it was #allObjectsDo:) that would never finish because of the block closure objects creation.<br>
<br>So...what about making the necessity of NOT sending a message or NOT introducing a suspension point more explicit? first we should have the support for that and second know each place where we need them. <br><br>The most basic thing I can think of is doing something like:<br>
<br>(ParseNode classVarNamed: 'StdSelectors') at: #== put: #bytecodedEqualEqual.<br>Compiler recompileAll. <br><br>And put a nice comment why one may want to use #optimizedEqualEqual. But again, in which places should I change #== for #bytecodedEqualEqual<br>
<br><br>Any thought or idea about them is really appreciated.<br><br>Thanks<br><br> <br>-- <br>Mariano<br><a href="http://marianopeck.wordpress.com" target="_blank">http://marianopeck.wordpress.com</a><br><br>