Hey,
so apparently I shot myself in the foot and created something like:
[[] repeat] fork.
with printCallStack() I can see it is running and activeProcess gives me the process. What I can't find is how to suspend/terminate that process. E.g. for the primtiveSuspend (or TerminateTo) I will need to prepare the call-stack.
Is there a way I can terminate such a process from the debugger?
cheers holger
On Tue, Oct 4, 2016 at 9:38 AM, Holger Freyther holger@freyther.de wrote:
Hey,
so apparently I shot myself in the foot and created something like:
[[] repeat] fork.
Which platform are you on? If I try this on the Mac, I can easily stop it with a user interrupt (Cmd-period).
- Bert -
On 04 Oct 2016, at 13:08, Bert Freudenberg bert@freudenbergs.de wrote:
On Tue, Oct 4, 2016 at 9:38 AM, Holger Freyther holger@freyther.de wrote:
Which platform are you on? If I try this on the Mac, I can easily stop it with a user interrupt (Cmd-period).
OSX. tried cmd-period but on restart with SqueakVM/OpenSmalltalkVM the UI is not even coming up and CPU spinning at 99%.
holger
On Tue, Oct 4, 2016 at 3:38 PM, Holger Freyther holger@freyther.de wrote:
with printCallStack() I can see it is running and activeProcess gives me the process. What I can't find is how to suspend/terminate that process. E.g. for the primtiveSuspend (or TerminateTo) I will need to prepare the call-stack.
Is there a way I can terminate such a process from the debugger?
Interesting challenge. I tried to replicate but in Linux Pharo 50760 doing "[[] repeat] fork" doesn't even lock the UI. So just some random guesses without being able to test them...
Perhaps you don't need to kill it, just lower its priority so the UI process takes precedence. I see in VMMaker, StackInterpreter>>printProcessStack: calls "self quickFetchInteger: PriorityIndex ofObject: proc" (which seems inlined) which calls #integerValueOf: for which the opposite seems to be #integerObjectOf: .
So maybe try tracing into printProcessStack() and once you have the oop for the priority, maybe push integerObjectOf(10) into it.
Or maybe try use #stObject:at:put or #storeInteger:ofObject:withValue: directly.
Another option may be putToSleepyieldingIf()
cheers -ben
Hi
2016-10-04 9:38 GMT+02:00 Holger Freyther holger@freyther.de:
Hey,
so apparently I shot myself in the foot and created something like:
[[] repeat] fork.
I tried it on latest Pharo on Mac. And no hang. Image continue working. UI start to be slower. But after killing process from ProcessBrowser everything works fine again
On Tue, Oct 4, 2016 at 3:01 PM, Denis Kudriashov dionisiydk@gmail.com wrote:
Hi
2016-10-04 9:38 GMT+02:00 Holger Freyther holger@freyther.de:
Hey,
so apparently I shot myself in the foot and created something like:
[[] repeat] fork.
I tried it on latest Pharo on Mac. And no hang. Image continue working. UI start to be slower.
In Squeak we have disabled processPreemptionYields to restore proper preemption semantics. That's why the above loop prevents the UI process from running.
Before, the VM always forced a process to yield if it was preempted, which made the scheduling non-deterministic. The time slice given to each process was random (whenever a higher-priority process became runnable). It did have the "advantage" of doing an implicit round-robin scheduling if multiple processes had the same priority. I guess that's what you're seeing in Pharo.
Cog supports both schemes via vmParameter 48.
- Bert -
Hi Bert.
2016-10-04 15:32 GMT+02:00 Bert Freudenberg bert@freudenbergs.de:
In Squeak we have disabled processPreemptionYields to restore proper preemption semantics. That's why the above loop prevents the UI process from running.
Does "proper preemption semantics" means that after high priority process died (or sleep) *previous* process continue execution? (if nothing new appears)
On Tue, Oct 4, 2016 at 3:39 PM, Denis Kudriashov dionisiydk@gmail.com wrote:
Hi Bert.
2016-10-04 15:32 GMT+02:00 Bert Freudenberg bert@freudenbergs.de:
In Squeak we have disabled processPreemptionYields to restore proper preemption semantics. That's why the above loop prevents the UI process from running.
Does "proper preemption semantics" means that after high priority process died (or sleep) *previous* process continue execution? (if nothing new appears)
Yes, the same process that was interrupted gets resumed.
- Bert -
vm-dev@lists.squeakfoundation.org