[squeak-dev] The Inbox: ToolBuilder-Kernel-nice.144.mcz

commits at source.squeak.org commits at source.squeak.org
Tue Apr 27 11:51:34 UTC 2021


Nicolas Cellier uploaded a new version of ToolBuilder-Kernel to project The Inbox:
http://source.squeak.org/inbox/ToolBuilder-Kernel-nice.144.mcz

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

Name: ToolBuilder-Kernel-nice.144
Author: nice
Time: 27 April 2021, 1:51:16.980651 pm
UUID: 89bbcc07-c286-4b42-b938-3ccee798d5fb
Ancestors: ToolBuilder-Kernel-nice.141

Fix ProgressInitiationException>>sendNotificationsTo: so that:
- the ProgressInitiationException remains inactive during workBlock evaluation
- unlesse explicitely rearmed
- active inner handlers remain active during workBlock evaluation

For the last goal, it is necessary to first resume, then evaluate the workBlock, hence usage of #resumeEvaluating:
This goes with Kernel-nice.1394 which implements this method as well as upgraded signal handling.

But if we resume, then we also reactivate current handler.
Generally, we do not want to reactivate current handler, unless explicit rearmHandlerDuring:, thus the intricated activate/deactivate dance.

=============== Diff against ToolBuilder-Kernel-nice.141 ===============

Item was changed:
+ ----- Method: ProgressInitiationException>>sendNotificationsTo: (in category 'handling') -----
- ----- Method: ProgressInitiationException>>sendNotificationsTo: (in category 'initialize-release') -----
  sendNotificationsTo: aNewBlock
+ 	"Resume execution using aNewBlock as workBlock value.
+ 	Note that the execution is resumed in signalContext (or outerContext).
+ 	This is done so that inner exception handlers be active during workBlock execution.
+ 	However, our own handlerContext should be deactivated, unless explicitely rearmed."
+ 	| mustDeactivateHandler |
+ 	mustDeactivateHandler := handlerContext notNil and: [handlerContext isHandlerActive not].
+ 	mustDeactivateHandler
+ 		ifTrue:
+ 			["The handlerContext is de-activated during handleSignal:
+ 			But it will be reactivated during unwinding when we will resumeEvaluating:
+ 			That's unwanted, we don't generally want to rearm the handler during workBlock evaluation.
+ 			Hence we have to deactivate it again inside the deferred block."
+ 			self resumeEvaluating:
+ 				[handlerContext deactivateHandler.
+ 				[workBlock value: [ :barVal |
+ 					aNewBlock value: minVal value: maxVal value: barVal]]
+ 						ensure: [handlerContext reactivateHandler]]]
+ 		ifFalse:
+ 			["If the handler is active at this step, then it must have been rearmed
+ 			with a #rearmHandlerDuring:
+ 			It's thus intentional to keep the handler active during workBlock evaluation"
+ 			self resumeEvaluating:
+ 				[workBlock value: [ :barVal |
+ 					aNewBlock value: minVal value: maxVal value: barVal]]]!
- 
- 	self reactivateHandlers; resumeUnchecked: (
- 		workBlock value: [ :barVal |
- 			aNewBlock value: minVal value: maxVal value: barVal
- 		]
- 	)
- !



More information about the Squeak-dev mailing list