> Am 26.01.2017 um 10:32 schrieb Clément Bera <bera.clem...@gmail.com>: > > > > On Thu, Jan 26, 2017 at 9:54 AM, Norbert Hartl <norb...@hartl.name > <mailto:norb...@hartl.name>> wrote: > >> Am 26.01.2017 um 08:11 schrieb Clément Bera <bera.clem...@gmail.com >> <mailto:bera.clem...@gmail.com>>: >> >> The "CAN'T REACH" comment is there because execution never reach that part >> of the code. If you write code there, it will never be executed. The process >> code performs a return without pushing any value on stack. >> > Because you return from the sender, right? > > Yes because the process code returns to the sender. > > In Smalltalk a send returns necessarily a value to be pushed on the stack of > the context performing the send. In the write barrier call-back, the context > is not performing a send, but an instance variable store. Unlike sends, > instance variable stores are not expected to push a value on stack. If the > call-back returns a value, it's pushed on stack while nothing is expected, > and if further code use values on stack it will use the returned value > instead of the correct one, furthermore, stack depth computation is messed > up, overflowing the context stack somewhere in the runtime memory leading to > data corruption.
I see. I'm not sure I understand it correctly. But isn't it the case that you return the value of attemptToAssign:index: as return value of the sender? In the current implementation it will return self. This would break any method with instVar access that do not return self. >> Signalling an error is safe if the error is never resumed. But you'll need >> the returnNoValue for performance intensive modification tracking. >> >> > Ok, while you are popping of the stack there is no way to return, right? I > cannot see what it has to be that way but I can see that my approach cannot > work this way. In my case the error is resumed because not resuming would > defeat the purpose of having transparent modification tracking. > > I'll use announcements for it because it is a better fit for that anyway. > > You can signal an error, but then keep the process code. For example: > > Object>>#attemptToAssign: value withIndex: index > | process | > NoModification signal. > process := Processor activeProcess. > [ process suspendedContext: process suspendedContext sender ] forkAt: > Processor activePriority + 1. > Processor yield. > > this method just works fine. > > However, > > Object>>#attemptToAssign: value withIndex: index > NoModification signal. > > this method does not work because it returns a value. > Ok, thanks. Norbert > > Norbert > >> >> On Wed, Jan 25, 2017 at 10:26 PM, Denis Kudriashov <dionisi...@gmail.com >> <mailto:dionisi...@gmail.com>> wrote: >> >> 2017-01-25 22:24 GMT+01:00 Denis Kudriashov <dionisi...@gmail.com >> <mailto:dionisi...@gmail.com>>: >> For the Process hack, it's because the call-back was designed to return no >> value. >> >> Now I am confused. >> Why anybody needs to return value from this method? >> And why there is "CAN'T REACH" comment at the end of method? >> Do you mean that method should never return? >> >> It may look like it works when returning a value but you will have uncommon >> crashes. >> >> And is it safe to just signal error? >> > >
