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

Best,
Marcel
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.
Best,
Jaromir
 
--
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>