[Cuis-dev] #terminate and #suspend update

Tue Aug 16 12:46:08 PDT 2022

Hi Juan,

I'm enclosing an update of #terminate and a revised version of #suspend.

There are two main reasons for this update:

(1) Currently the process that sends #terminate won't wait for the process being terminated to finish its termination if the process being terminated e.g. inserts a delay in an unwind block (see #testTerminateWithDelayInUnwind). To fix this deficiency I've engaged a semaphore to synchronize the two processes. In addition, I've added a bit more powerful guard (see #unwindAndStop:) to make sure a process is correctly terminated even in case of multiple concurrent termination attempts, and a few minor fixes for edge cases. This updated approach passed all Squeak’s and Pharo’s tests :) I'll be sending more tests later after I'll adapt my Squeak versions; apologies. (Changed methods: #terminate, #unwindTo:, #runUntilReturnFrom:; added methods: #suspendAndReleaseCriticalSection, #unwindAndStop:)

(2) Eliot implemented a revised process suspend semantics in primitive 578. The original suspend semantics (in primitive 88) is flawed and allows a process waiting on a semaphore (or mutex in Squeak) to leave the semaphore even without receiving a signal: the original suspend primitive 88 simply removes the process from the semaphore. The new suspend primitive 578 backs up the process's pc by "one instruction", i.e. to the send that placed the process in the semaphore queue; it means that when the process resumes it reenters the wait state. Check #testSuspendAndResume. (Changed methods: #suspend, #signalException:, #signalWaitingProcess; added methods: #suspendAndUnblock:, #processSuspensionUnblocks)

Both "fixes" can be implemented independently but for simplicity I'm sending them both in one package; should you decide to implement just fix at a time I can separate them.

While the #terminate fix is just improving the current behavior (and most likely not breaking any existing code) the #suspend fix may be a bit different story:

Considerations:

i) there may be some existing external code (ab)using the flawed behavior of primitive 88 -> for this scenario the old behavior has been retained in #suspendAndUnblock method. It may be useful but must be used with caution.

ii) there are a few methods even in the core taking advantage of the old behavior: Process >> #signalException: and DelayWaitTimeout >> #signalWaitingProcess - check the fixed code. (Cuis has also Process >> #signal but I'm not sure what its purpose is compared to #signalException: - please advise)

iii) in the new release VM (3185) there are in fact two new suspend primitives: #578 and #568; the only difference is the return value: #568 returns the list the suspended process was previously waiting at (the same return semantics as primitive #88) while #578 returns nil if the process's pc was backed up; after a debate with Eliot and Nicolas, Squeak uses 578 but it's no problem to use 568 instead.

iv) #testAtomicSuspend uses #suspendPrimitivelyOrFail - I'd suggest changing the primitive suspend to 578 and modify the test but I'm not sure how you decide to proceed; maybe test both primitives?

v) Eliot has also added to Squeak a new method #processSuspensionUnblocks accessing vmParameterAt: 65 which indicates whether the VM provides the new suspend primitives. I'm just mentioning it FYI and enclosing the code for your consideration (with Eliot's authorship).

Juan, please let me know what you think and whether you plan to use the new #suspend. Thanks again for implementing the UI fixes - without them the new #terminate would freeze the UI for many innocent examples :) (...because #terminate operates inside the ensure argument block and now *waits* there until the process being terminated finishes its termination and that would indeed freeze the UI in case of an unwind error).

If you spot any issue or inconsistency please let me know; I'll be away for a few days but back for the weekend.

Best regards,
Jaromir

--

Jaromír Matas

mail at jaromir.net

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20220816/8bbbb384/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 5435-CuisCore-JaromirMatas-2022Aug15-12h47m-jar.tests.cs.st
Type: application/octet-stream
Size: 2217 bytes
Desc: 5435-CuisCore-JaromirMatas-2022Aug15-12h47m-jar.tests.cs.st
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20220816/8bbbb384/attachment-0002.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 5435-CuisCore-JaromirMatas-2022Aug15-12h47m-jar.code.cs.st
Type: application/octet-stream
Size: 12201 bytes
Desc: 5435-CuisCore-JaromirMatas-2022Aug15-12h47m-jar.code.cs.st
URL: <http://lists.cuis.st/mailman/archives/cuis-dev/attachments/20220816/8bbbb384/attachment-0003.obj>