On Thu, Jan 26, 2017 at 9:54 AM, Norbert Hartl <norb...@hartl.name> wrote:
> > Am 26.01.2017 um 08:11 schrieb Clément Bera <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. > 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. > Norbert > > > On Wed, Jan 25, 2017 at 10:26 PM, Denis Kudriashov <dionisi...@gmail.com> > wrote: > >> >> 2017-01-25 22:24 GMT+01:00 Denis Kudriashov <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? >> > > >
