6293LowSpaceWatcherFix-dtl considered harmful

stéphane ducasse ducasse at iam.unibe.ch
Thu Mar 31 09:49:40 UTC 2005


Hi andreas

Indeed it looks like. I checked all the three version of the methods 
(see below).

If I'm correct I think that this is was one fix against getting image 
completely trashing (at least on mac). At least people suggested to
me to load that cs in my image when I could not even halt the system 
anymore. This is a REAL problem for the environment
that will support my new book, since kids playing with conditional 
loops will write endless loops and if ctrl . does not work, I'm fucked 
up.
because they will throw everything together.  So I would love to have a 
system where you can ALWAYS get a debugger or stop a crazy computation.

I posted several anxious posts on this KEY behavior in the past. If I'm 
correct david is the guy doing the ProcessBrowser so I'm sure that the 
harvester was believing in him.  And I do not know who pushed that in 
the stream but I would not blame him. See my previous sentence.
And yes the reviewing process could be improved, but as usual nobody is 
really doing anything except his current most
urgent task so....nothing good can happen with a process like that.

Stef

> Trying to track a problem in Tweak I ran into the above mentioned 
> update. I won't comment on the process of how it got into the image (I 
> think you all know my opinion about eyeballing system-critical changes 
> and I am almost certain that the approval went something like "oh, 
> what possible harm could a one-line change do") but I am rather 
> interested in what problem this is trying to fix.
>
> The comment of the change set states: "The low space watcher is 
> interrupted in the context of the wrong process when the eventTickler 
> process (or other high priority process) is running. This prevents low 
> space detection from functioning properly."
>
> But this makes no sense whatsoever. The low space watcher can be only 
> be interrupted if it is running (non-running processes are never 
> interrupted) but all the running low space watcher does is to throw up 
> an interrupt (which we all agree on is the right thing to do) on the 
> currently active process. If the user presses Alt-period when this 
> happens why would it be wrong to interrupt the low space watcher?
>
> It is precisely the right thing to do (in fact, it is the only thing 
> that can be done if we are to honor the user interrupt). If we choose 
> to *ignore* the actual running process (such as is done in the above 
> update) and just arbitrarily interrupt the "main" project process we 
> will never be able to interrupt any run-away process which is 
> different from the main process. As an example, take:
>
> 	[[true] whileTrue:[]]]
> 		forkAt: Processor userSchedulingPriority+1.
>
> With the original version of the method you *were* able to interrupt 
> that process (try it - revert to its previous version run the above 
> and hit alt-period). With the version of the method in the update you 
> will not be able to interrupt a runaway process like the above.

Andreas in my image I have three version the latest is a fix of ned

interruptName: labelString
	"Create a Notifier on the active scheduling process with the given 
label."
	| preemptedProcess projectProcess suspendingList |
	Smalltalk isMorphic ifFalse:
		[^ ScheduledControllers interruptName: labelString].
	ActiveHand ifNotNil:[ActiveHand interrupted].
	ActiveWorld := World. "reinstall active globals"
	ActiveHand := World primaryHand.
	ActiveWorld _ World. "reinstall active globals"
	ActiveHand _ World primaryHand.
	ActiveHand interrupted. "make sure this one's interrupted too"
	ActiveEvent := nil.
	BotProcess interrupted.
	ActiveEvent _ nil.

	projectProcess := self uiProcess.	"we still need the accessor for a 
while"
	preemptedProcess := Processor preemptedProcess.
	projectProcess _ self uiProcess.	"we still need the accessor for a 
while"
	preemptedProcess _ Processor preemptedProcess.
	"Only debug preempted process if its priority is >= projectProcess' 
priority"
	preemptedProcess priority < projectProcess priority ifTrue:[
		(suspendingList := projectProcess suspendingList) == nil
		(suspendingList _ projectProcess suspendingList) == nil
			ifTrue: [projectProcess == Processor activeProcess
						ifTrue: [projectProcess suspend]]
			ifFalse: [suspendingList remove: projectProcess ifAbsent: [].
					projectProcess offList].
		preemptedProcess := projectProcess.
		preemptedProcess _ projectProcess.
	] ifFalse:[
		preemptedProcess suspend offList.
		preemptedProcess _ projectProcess suspend offList.
	].
	Debugger openInterrupt: labelString onProcess: preemptedProcess



I tried reverting to the code of dan and I could stop it, open a 
debugger and it worked
I tried also with the version of ned and I could stop it too.
I tried with the version of dtl and I could stop it but I could not get 
a debugger and the system
was kind of freezing....

So I hope this helps.

> Whatever this update is trying to address, it cannot possibly be what 
> is being claimed in the preamble. So what problem is this update 
> trying to solve?

We should really solve that point because this is important.
I got strange problem wwhen having a bug in the bounds methods of 
certain morphs and was in a situation where I could not
get a debugger and having systematically the system trashing. I 
reported that too.

Stef

>
> Cheers,
>   - Andreas
>




More information about the Squeak-dev mailing list