[squeak-dev] The Trunk: Kernel-eem.1484.mcz
Jaromir Matas
mail at jaromir.net
Sun Jun 26 17:03:28 UTC 2022
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<mailto:eliot.miranda at gmail.com>
Sent: Saturday, June 25, 2022 21:12
To: The general-purpose Squeak developers list<mailto: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<mailto: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<mailto:commits at source.squeak.org>
Sent: Saturday, June 25, 2022 1:58
To: squeak-dev at lists.squeakfoundation.org<mailto:squeak-dev at lists.squeakfoundation.org>; packages at lists.squeakfoundation.org<mailto: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220626/b660e236/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signalException stack top bug - before pop.png
Type: image/png
Size: 81499 bytes
Desc: signalException stack top bug - before pop.png
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220626/b660e236/attachment-0001.png>
More information about the Squeak-dev
mailing list
|