Hi Marcel,

On Mon, Jun 27, 2022 at 12:38 AM Marcel Taeumel <marcel.taeumel at hpi.de>
wrote:

> Hi Eliot, hi Jaromir --
>
> Please resolve this issue ASAP. I did not expect such a commit given that
> we are in "CODE FREEZE" at this point. A short notice/discussion would have
> been nice.
>

Done.  Apologies for the disturbance,.  I will say that inter-process
signalling is really useful and the old implementation was broken, so it's
nice to have a fix.

>
> Yet, thanks for working on this issue. :-) Can we leave it as is or is
> another change required?
>

The final change has been committed.  Jaromir found the fix. (Thanks
Jaromir!)

>
> Best,
> Marcel
>
> Am 26.06.2022 23:57:23 schrieb Jaromir Matas <mail at jaromir.net>:
>
> Hi Eliot,
>
>
>
> How about like this:
>
> signalException: anException
>
>                 "Signal an exception in the receiver process...if the
> receiver is currently
>
>                 suspended, the exception will get signaled when the
> receiver is resumed.  If
>
>                 the receiver is blocked on a Semaphore, it will be
> immediately re-awakened
>
>                 and the exception will be signaled; if the exception is
> resumed, then the receiver
>
>                 will return to a blocked state unless the blocking
> Semaphore has excess signals"
>
>                 | oldList |
>
>                 "If we are the active process, go ahead and signal the
> exception"
>
>                 self isActiveProcess ifTrue: [^anException signal].
>
>
>
>                 "Suspend myself first to ensure that I won't run away in
> the
>
>                 midst of the following modifications."
>
>                 (oldList := myList) ifNotNil: [self suspend].
>
>
>
>                 suspendedContext ifNil: [self error: 'no suspended
> context!!'].
>
>
>
>                 "Add a new method context to the stack that will signal
> the exception"
>
>                 suspendedContext := Context
>
>                                 sender: suspendedContext
>
>                                 receiver: self
>
>                                 method: (self class lookupSelector:
> #pvtSignal:)
>
>                                 arguments: {anException}.
>
>
>
>                 "If we are not on a list to be run (i.e. this process is
> suspended), then when the
>
>                 process is resumed, it will signal the exception"
>
>
>
>                 oldList ifNotNil: [self resume]
>
>
>
>
>
> pvtSignal: anException
>
>                 "Private. This method is used to signal an exception from
> another
>
>                 process...the receiver must be the active process."
>
>
>
>                 "Since this method is not called in a normal way, we need
> to take care
>
>                 that it doesn't directly return to the caller (because I
> believe that could
>
>                 have the potential to push an unwanted object on the
> caller's stack)."
>
>
>
>                 | blocker |
>
>                 self isActiveProcess ifFalse: [^self].
>
>                 anException signal.
>
>                 blocker := Semaphore new.
>
>                 [self suspend.
>
>                 suspendedContext := suspendedContext swapSender: nil.
>
>                 self resume] fork.
>
>                 blocker wait.
>
>
>
> --
>
> *Jaromír Matas*
>
> mail at jaromir.net
>
>
>
> *From: *Jaromir Matas <mail at jaromir.net>
> *Sent: *Sunday, June 26, 2022 20:41
> *To: *The general-purpose Squeak developers list
> <squeak-dev at lists.squeakfoundation.org>
> *Subject: *Re: [squeak-dev] The Trunk: Kernel-eem.1484.mcz
>
>
>
> Hi Eliot,
>
>
>
> I think the MNU error situation corresponds to the scenario described in
> pvtSignal:list:; unless I’m mistaken or you find more elegant way I’d
> suggest to use the helper method again; fortunately nicely simplified
> thanks to the new suspend:
>
>
>
> pvtSignal: anException
>
>                 "Private. This method is used to signal an exception from
> another
>
>                 process...the receiver must be the active process."
>
>
>
>                 "Since this method is not called in a normal way, we need
> to take care
>
>                 that it doesn't directly return to the caller (because I
> believe that could
>
>                 have the potential to push an unwanted object on the
> caller's stack)."
>
>
>
>                 | blocker |
>
>                 self isActiveProcess ifFalse: [^self].
>
>                 anException signal.
>
>                 blocker := Semaphore new.
>
>                 [self suspend.
>
>                 suspendedContext := suspendedContext swapSender: nil.
>
>                 self resume] fork.
>
>                 blocker wait.
>
>
>
> What do you think?
>
> Best,
>
> Jaromir
>
>
>
>
>
> *From: *Jaromir Matas <mail at jaromir.net>
> *Sent: *Sunday, June 26, 2022 19:03
> *To: *The general-purpose Squeak developers list
> <squeak-dev at lists.squeakfoundation.org>
> *Subject: *Re: [squeak-dev] The Trunk: Kernel-eem.1484.mcz
>
>
>
> Hi Eliot,
>
>
>
> Thanks for the examples; I have a problem with this one:
>
>
>
> p := [Semaphore new wait] fork.
>
> Processor yield.
>
> p signalException: Notification
>
>
>
> It gives me MNU: UndefinedObject>>wait
>
>
>
> The reason is:
>
> 1) you place the new context (Notification signal) on top of the previous
> suspendedContext (Semaphore new wait); its pc is at the wait.
>
> 2) now when the (Notification signal) context finally returns it places
> its return value on the top of its senders stack -> and this is a problem
> because when you send the wait it takes the stack top as the receiver (but
> that’s changed in the meantime) if I understand it correctly – resulting in
> the MNU
>
>
>
> Is this a bug? I’ve never used #signalException so I’m not entirely sure
> what to expect from it but it behaves differently than in 5.3.
>
>
>
> Enclosing a screen snip. If, at that moment, you do suspendedContext pop,
> the computation will proceed as expected.
>
>
>
> I’ll keep looking at it but wanted to let you know…
>
>
>
> Thanks,
>
> Jaromir
>
>
>
> --
>
> *Jaromír Matas*
>
> mail at jaromir.net
>
>
>
> *From: *Eliot Miranda <eliot.miranda at gmail.com>
> *Sent: *Saturday, June 25, 2022 21:12
> *To: *The general-purpose Squeak developers list
> <squeak-dev at lists.squeakfoundation.org>
> *Subject: *Re: [squeak-dev] The Trunk: Kernel-eem.1484.mcz
>
>
>
>
>
>
>
> On Sat, Jun 25, 2022 at 1:50 AM Jaromir Matas <mail at jaromir.net> wrote:
>
> Hi Eliot,
>
> I missed that one, sorry.
>
> I’ve just tried this example and only got an assertion error (without your
> fix):
>
>
>
> p := [] newProcess suspendedContext: nil.
>
> p signalException: Error
>
>
>
> I just can’t figure out in which case you got the BCR exception :)
>
>
>
> In the VMMaker VM simulator, when the simulator window is closed, the
> closing code attempts to close any and all notifiers & debuggers .  I'm
> working on the threaded FFI plugin, which in the simulator has multiple
> Smalltalk processes emulating OS threads.  To close each notifier it needs
> to deliver a tagged Notification signal to the relevant process.  Some of
> these processes are waiting on semaphores.  If they are the old code would
> suspend, which would set the process's suspendedContext to nil, and result
> in a cannot return error as the signal was being delivered.
>
>
>
> So the example to test is
>
>
>
> p := [Semaphore new wait] fork.
>
> Processor yield.
>
> p signalException: Notification
>
>
>
> With the old signalException: version and the new suspend primitive this
> would crash with the BCR error.  Or something like that.  Maybe it had to
> be terminated, as in
>
>
>
> p := [Semaphore new wait] fork.
>
> Processor yield.
>
> p terminate.
>
> p signalException: Notification
>
>
>
> But you get the idea.  If the process's suspendedContext is nil then the
> context that is put on top of the stack towards the end of signalException:
> will not be able to return.
>
>
>
> Thanks!
>
> Jaromir
>
>
>
> *From: *commits at source.squeak.org
> *Sent: *Saturday, June 25, 2022 1:58
> *To: *squeak-dev at lists.squeakfoundation.org;
> packages at lists.squeakfoundation.org
> *Subject: *[squeak-dev] The Trunk: Kernel-eem.1484.mcz
>
>
>
> Eliot Miranda uploaded a new version of Kernel to project The Trunk:
> http://source.squeak.org/trunk/Kernel-eem.1484.mcz
>
> ==================== Summary ====================
>
> Name: Kernel-eem.1484
> Author: eem
> Time: 24 June 2022, 4:58:09.258613 pm
> UUID: f8ca934f-5875-434a-8cec-4d055099bdb6
> Ancestors: Kernel-mt.1483
>
> Fix a bug in Process>>signalException: where signalling a suspended
> process would cause a cannot return exception.
>
> =============== Diff against Kernel-mt.1483 ===============
>
> Item was changed:
>   ----- Method: Process>>signalException: (in category 'signaling') -----
>   signalException: anException
>          "Signal an exception in the receiver process...if the receiver is
> currently
>          suspended, the exception will get signaled when the receiver is
> resumed.  If
>          the receiver is blocked on a Semaphore, it will be immediately
> re-awakened
>          and the exception will be signaled; if the exception is resumed,
> then the receiver
>          will return to a blocked state unless the blocking Semaphore has
> excess signals"
>
>          "If we are the active process, go ahead and signal the exception"
>           self isActiveProcess ifTrue: [^anException signal].
>
>          "Suspend myself first to ensure that I won't run away
>           in the midst of the following modifications."
> +        self isSuspended ifFalse:
> +                [self suspend].
> +        suspendedContext ifNil: [self error: 'no suspended context!!!!'].
> +        suspendedContext := Context
> -         self suspend.
> -         suspendedContext := Context
>                                                                  sender:
> suspendedContext
>                                                                  receiver:
> anException
>                                                                  method:
> (anException class lookupSelector: #signal)
>
> arguments: #().
> +        ^self resume!
> -         ^self resume!
>
>
>
>
>
>
>
>
> --
>
> _,,,^..^,,,_
>
> best, Eliot
>
>
>
>
>
>
>
>
>

-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220627/9d275d33/attachment-0001.html>