[squeak-dev] Revised suspend: possible need for a fix in SqueakMap (?)

Marcel Taeumel marcel.taeumel at hpi.de
Wed Jun 15 10:32:24 UTC 2022

Hi Jaromir --

I am not quite sure that I understand this concern. Are your describing an "anti pattern" or old workaround here? So, some old code does suspend+resume to explicitly bypass a semaphore? Hmm...

Am 15.06.2022 11:22:01 schrieb Jaromir Matas <mail at jaromir.net>:
Hi Marcel, all,
Jakob spotted an issue with Squot after introducing the revised #suspend semantics (prim 578) and the latest version of #terminate.
I found a pattern in Squot where you suspend and resume a process: if the process was on a semaphore the new #suspend semantics would change the behavior of the computation; however we don’t know yet whether this is the cause of Squot’s issue.
The same pattern:
                oldUIProcess suspend.
                Project resumeProcess: oldUIProcess.
is used in InstallerSqueakMap >> #update so I wonder whether this might be an issue too. I have no experience with SqueakMap and don’t know how to find out whether InstallerSqueakMap >> #update works as intended or whether a fix is necessary; could possibly somebody experienced verify?
The fix should be straightforward: use #suspendAndUnblock instead of #suspend to revert to the previous semantics (prim 88) in this particular case.
Thanks for your help.
Jaromír Matas
mail at jaromir.net
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220615/5202fca4/attachment.html>

More information about the Squeak-dev mailing list