Hi Jaromir,

On Sun, Jun 26, 2022 at 10:03 AM Jaromir Matas <mail at jaromir.net> wrote:

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

It's a bug in the implementation of signalException:.  I should have seen
it earlier.  It is the reason Context>>#jump exists.  Let me think about
the right solution for a while and I'll commit a fix soon.


>
> 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/6919d942/attachment-0001.html>