Hi Jaromir --

If you do new stuff, try to base it on some recent version in Trunk, not some older version in the Inbox.

Best,
Marcel
Am 09.06.2022 11:41:02 schrieb Jaromir Matas <mail at jaromir.net>:
Hi Marcel,
 
> Due to that ancestry of 1478, 1475 is now in Trunk as well. Is this a problem or did you revise your concerns from here?
 
I really need more education about this :) I just kept piling the changes without thinking… 1475 was insufficient and was updated (superseded?) by 1476. I don’t know what the consequences of keeping 1475 in the Trunk are though. From my naïve position as long as the contents of 1475 doesn’t show up in the versions history, I’m ok.
 
Thank you!
Best,
Jaromir
 
--
Jaromír Matas
mail at jaromir.net
 
From: Marcel Taeumel [mailto:marcel.taeumel at hpi.de]
Sent: Thursday, June 9, 2022 10:30
To: squeak-dev [mailto:squeak-dev at lists.squeakfoundation.org]
Subject: Re: [squeak-dev] The Inbox: Kernel-jar.1475.mcz
 
Hi Jaromir --
 
Due to that ancestry of 1478, 1475 is now in Trunk as well. Is this a problem or did you revise your concerns from here?
 
Best,
Marcel
Am 06.06.2022 11:21:13 schrieb Jaromir Matas <mail at jaromir.net>:
Hi Marcel,
 
I’d like to withdraw this changeset; I still think the assumption that the process terminating another process should wait until the termination is completed is valid but it’ll need some more thinking: one of the side-effects is if you terminate a process like this:
                p := [  [Semaphore new wait] ensure: [^2] ] fork.
From the UI, like this:
                p terminate
you freeze the UI – because it waits for p to terminate but p attempts to open a debugger in the UI :)
 
Something like this
                q := [p terminate] fork
works fine, indeed.
 
So my suggestion is to leave #terminate as is (it’s still an improvement against the previous) and keep the 'testTerminateWithDelayInUnwind' in expected failures as a reminder. The rest of the tests I sent earlier are still valid.
 
Best,
 
--
Jaromír Matas
+420 777 492 777
mail at jaromir.net
 
From: commits at source.squeak.org [mailto:commits at source.squeak.org]
Sent: Saturday, June 4, 2022 22:32
To: squeak-dev at lists.squeakfoundation.org [mailto:squeak-dev at lists.squeakfoundation.org]
Subject: [squeak-dev] The Inbox: Kernel-jar.1475.mcz
 
A new version of Kernel was added to project The Inbox:
http://source.squeak.org/inbox/Kernel-jar.1475.mcz [http://source.squeak.org/inbox/Kernel-jar.1475.mcz]

==================== Summary ====================

Name: Kernel-jar.1475
Author: jar
Time: 4 June 2022, 10:31:44.661893 pm
UUID: 923d5402-9a8d-0a48-87d7-44c56400dd0c
Ancestors: Kernel-jar.1474

Fix a scenario when a delay or yield inside unwind blocks may cause control be handed over to the original process which may be assuming the termination has completed. (A higher priority for termination is indeed not a solution)

A process that invokes termination of another process is assumed to wait until the terminating process finishes unwinding itself. This may be useful during cleanup operations requiring e.g. waiting for resources etc.

A complementing test 'testTerminateWithDelayInUnwind' is part of the additional collection of tests in KernelTests-jar.428.

=============== Diff against Kernel-jar.1474 ===============

Item was changed:
  ----- Method: Process>>terminate (in category 'changing process state') -----
  terminate
         "Stop the process that the receiver represents forever.
          Unwind to execute pending #ensure:/#ifCurtailed: blocks before terminating;
+         allow all unwind blocks to run; if they are currently in progress, let them finish."
-         allow all unwind blocks to run; if they are currently in progress, let them finish.
-         If the process is in the middle of a #critical: critical section, release it properly."
        
+         "This is the kind of behavior we expect when terminating a healthy process.
-        "This is the kind of behavior we expect when terminating a healthy process.
          See further comments in #terminateAggressively and #destroy methods dealing
+         with process termination when closing the debugger or after a catastrophic failure.
+        
+         If terminating the active process, create a new stack and run unwinds from there.
-         with process termination when closing the debugger or after a catastrophic failure."
        
+         If terminating a suspended process (including runnable and blocked), always
+         suspend the terminating process first so it doesn't accidentally get woken up.
+         Equally important is the side effect of the suspension: In 2022 a new suspend
+         semantics has been introduced: the revised #suspend backs up a process waiting
+         on a conditional variable to the send that invoked the wait state, while the previous
+         #suspend simply removed the process from the conditional variable's list it was
+         previously waiting on; see #suspend and #suspendAndUnblock comments.
-        "If terminating the active process, create a parallel stack and run unwinds from there;
-         if terminating a suspended process, again, create a parallel stack for the process being
-         terminated and resume the suspended process to complete its termination from the new
-         parallel stack. Use a priority higher than the active priority to make the process that
-         invoked the termination wait for its completion."
 
+         If the process is in the middle of a #critical: critical section, release it properly.
+       
+         To allow a suspended process to unwind itself, create a new stack for the process
+         being terminated and resume the suspended process to complete its termination
+         from the new parallel stack. Use a semaphore to make the process that invoked
+         the termination wait for self's completion. Execute the termination in the ensure
+         argument block to ensure it completes even if the terminator process itself gets
+         terminated before it's finished; see testTerminateInTerminate."
+       
-        "If terminating a suspended process (including runnable and blocked), always suspend
-         the terminating process first so it doesn't accidentally get woken up. Equally important is
-         the side effect of the suspension; In 2022 a new suspend semantics has been introduced:
-         the revised #suspend backs up a process waiting on a conditional variable to the send that
-         invoked the wait state, while the pre-2022 #suspend simply removed the process from
-         the conditional variable's list it was previously waiting on; see Process>>suspend comments.
-         Execute the termination in the ensure argument block to ensure it completes even if the
-         terminator process itself gets terminated before it's finished; see testTerminateInTerminate."
-
         | context |
         self isActiveProcess ifTrue: [
                 context := thisContext.
                 ^[context unwindTo: nil. self suspend] asContext jump].
 
+        [] ensure: [ | terminator |
-        [] ensure: [
                 self suspendAndReleaseCriticalSection.
                 context := suspendedContext ifNil: [^self].
+                terminator := Semaphore new.
+                suspendedContext := [context unwindTo: nil. terminator signal. self suspend] asContext.
+                self priority: Processor activePriority; resume.
+                terminator wait]!
-                suspendedContext := [context unwindTo: nil. self suspend] asContext.
-                self priority: (Processor activePriority + 1 min: Processor highestPriority); resume]!



 
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220609/11f0810b/attachment.html>