[squeak-dev] The Inbox: Kernel-jar.1475.mcz
eliot.miranda at gmail.com
Tue Jun 7 18:09:49 UTC 2022
On Mon, Jun 6, 2022 at 2:21 AM Jaromir Matas <mail at jaromir.net> wrote:
> 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.
> *Jaromír Matas*
> +420 777 492 777
> mail at jaromir.net
> *From: *commits at source.squeak.org
> *Sent: *Saturday, June 4, 2022 22:32
> *To: *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:
> ==================== 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')
> "Stop the process that the receiver represents forever.
> Unwind to execute pending #ensure:/#ifCurtailed: blocks before
> + 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
> - "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]
> - self priority: (Processor activePriority + 1 min:
> Processor highestPriority); resume]!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Squeak-dev