[Pharo-project] froze image just
trying to publish a slice on my harddisc without networkâ¦. and I could not interrupt anything. No cmd+. no interdiction sign did anything :( So is it normal? Not being able to interrupt something is a pain. stef
On 30 Apr 2013, at 22:44, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
trying to publish a slice on my harddisc without networkâ¦. and I could not interrupt anything. No cmd+. no interdiction sign did anything :(
So is it normal? Not being able to interrupt something is a pain.
stef
Could be networking related, publishing a slice needs many network interactions, most of them are retried at least once; they all have to time out. The default timeout is 30s. On the other hand, I just turned off my wireless network and tried an MC operation and it immediately throws an NameLookupFailure exception, way before the 30s deadline. Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org
On 2013-04-30, at 23:39, Sven Van Caekenberghe <sven@stfx.eu> wrote:
On 30 Apr 2013, at 22:44, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
trying to publish a slice on my harddisc without networkâ¦. and I could not interrupt anything. No cmd+. no interdiction sign did anything :(
So is it normal? Not being able to interrupt something is a pain.
I experience similar issues with internet and missing passwords :)
Could be networking related, publishing a slice needs many network interactions, most of them are retried at least once; they all have to time out. The default timeout is 30s.
On the other hand, I just turned off my wireless network and tried an MC operation and it immediately throws an NameLookupFailure exception, way before the 30s deadline.
Sven
On 30 April 2013 22:44, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
trying to publish a slice on my harddisc without networkâ¦. and I could not interrupt anything. No cmd+. no interdiction sign did anything :(
So is it normal? Not being able to interrupt something is a pain.
stef
the problem stems from the point that when you press cmd+. an interrupt process logic looking for some other active process to stop it.. now since UI process blocked by semaphore, as well as rest, it finds nothing to interrupt and ignores it :) i think we should think about it, like putting synthesized context with '1halt', to UI process, so when it will awake, it will be halted. Or... if interrupt handler found nothing, then always spawn new UI process opening debugger on old one. -- Best regards, Igor Stasenko.
On May 1, 2013, at 2:31 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 30 April 2013 22:44, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
trying to publish a slice on my harddisc without networkâ¦. and I could not interrupt anything. No cmd+. no interdiction sign did anything :(
So is it normal? Not being able to interrupt something is a pain.
stef
the problem stems from the point that when you press cmd+. an interrupt process logic looking for some other active process to stop it.. now since UI process blocked by semaphore, as well as rest, it finds nothing to interrupt and ignores it :)
i think we should think about it, like putting synthesized context with '1halt', to UI process, so when it will awake, it will be halted.
Or... if interrupt handler found nothing, then always spawn new UI process opening debugger on old one.
Yes igor because the experience is not good. I added https://pharo.fogbugz.com/default.asp?10466 so that we do not forget it Stef
-- Best regards, Igor Stasenko.
What? I am 99.99% sure it used to interrupt the GUI process if no other viable candidate could be found, why change that? At least in my mind, if you hit cmd - dot, either you want to interrupt some process blocking the UI on a higher priority, or you want the UI process itself. For everything else, there's the Process Browser. Cheers, Henry On May 1, 2013, at 2:31 AM, Igor Stasenko wrote:
On 30 April 2013 22:44, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
trying to publish a slice on my harddisc without networkâ¦. and I could not interrupt anything. No cmd+. no interdiction sign did anything :(
So is it normal? Not being able to interrupt something is a pain.
stef
the problem stems from the point that when you press cmd+. an interrupt process logic looking for some other active process to stop it.. now since UI process blocked by semaphore, as well as rest, it finds nothing to interrupt and ignores it :)
i think we should think about it, like putting synthesized context with '1halt', to UI process, so when it will awake, it will be halted.
Or... if interrupt handler found nothing, then always spawn new UI process opening debugger on old one.
-- Best regards, Igor Stasenko.
On 2 May 2013 09:54, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
What? I am 99.99% sure it used to interrupt the GUI process if no other viable candidate could be found, why change that? At least in my mind, if you hit cmd - dot, either you want to interrupt some process blocking the UI on a higher priority, or you want the UI process itself. For everything else, there's the Process Browser.
It was never like that. It was always looking for a process which is scheduled, but not interrupt process itself. usually that meant it interrupts things like finalization process, so i added logic to avoid interrupting it unless there's nothing else to interrupt. The problem is that if process is waiting for semaphore (and UI process doing it quite often) the interrupt handler cannot detect it. Because 1) it is not scheduled 2) even if you iterate over Process allInstances and ask #isSuspended to it, it will answer true while 1) is fine, 2) is a design flaw i am talking about: - there is no way to discriminate between process which waits on semaphore and suspended process (which has no chances to run unless you send #resume to it, and therefore no need to interrupt)
Cheers, Henry
-- Best regards, Igor Stasenko.
On May 2, 2013, at 2:50 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 2 May 2013 09:54, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
What? I am 99.99% sure it used to interrupt the GUI process if no other viable candidate could be found, why change that? At least in my mind, if you hit cmd - dot, either you want to interrupt some process blocking the UI on a higher priority, or you want the UI process itself. For everything else, there's the Process Browser.
It was never like that. It was always looking for a process which is scheduled, but not interrupt process itself. usually that meant it interrupts things like finalization process, so i added logic to avoid interrupting it unless there's nothing else to interrupt.
The problem is that if process is waiting for semaphore (and UI process doing it quite often) the interrupt handler cannot detect it. Because 1) it is not scheduled 2) even if you iterate over Process allInstances and ask #isSuspended to it, it will answer true
while 1) is fine, 2) is a design flaw i am talking about: - there is no way to discriminate between process which waits on semaphore and suspended process (which has no chances to run unless you send #resume to it, and therefore no need to interrupt)
thanks for the explanation. Stef
Cheers, Henry
-- Best regards, Igor Stasenko.
On May 2, 2013, at 2:50 PM, Igor Stasenko wrote:
On 2 May 2013 09:54, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
What? I am 99.99% sure it used to interrupt the GUI process if no other viable candidate could be found, why change that? At least in my mind, if you hit cmd - dot, either you want to interrupt some process blocking the UI on a higher priority, or you want the UI process itself. For everything else, there's the Process Browser.
It was never like that. It was always looking for a process which is scheduled, but not interrupt process itself. usually that meant it interrupts things like finalization process, so i added logic to avoid interrupting it unless there's nothing else to interrupt.
From 1.4: handleUserInterrupt [|toInterrupt| toInterrupt := Processor preemptedProcess. "Only interrupt processes which are potentially blocking the UI" toInterrupt priority < UIManager default uiProcess priority ifTrue: [toInterrupt := Project uiProcess].
So yes, it was like that. (barring the other flaws you mentioned, about potentially interrupting critical high-priority processes) Cheers, Henry
On 2 May 2013 15:33, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
On May 2, 2013, at 2:50 PM, Igor Stasenko wrote:
On 2 May 2013 09:54, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
What? I am 99.99% sure it used to interrupt the GUI process if no other viable candidate could be found, why change that? At least in my mind, if you hit cmd - dot, either you want to interrupt some process blocking the UI on a higher priority, or you want the UI process itself. For everything else, there's the Process Browser.
It was never like that. It was always looking for a process which is scheduled, but not interrupt process itself. usually that meant it interrupts things like finalization process, so i added logic to avoid interrupting it unless there's nothing else to interrupt.
From 1.4: handleUserInterrupt [|toInterrupt| toInterrupt := Processor preemptedProcess. "Only interrupt processes which are potentially blocking the UI" toInterrupt priority < UIManager default uiProcess priority ifTrue: [toInterrupt := Project uiProcess].
So yes, it was like that. (barring the other flaws you mentioned, about potentially interrupting critical high-priority processes)
Okay, then we need to change #ifNil clause in following method to just interrupt UI process, instead of showing useless "not interruptable" message: handleUserInterrupt "This will be called from the event-fetcher process. Assume no system-vital processes have a lower priority than this, and are thus ok to interrupt" UserInterruptHandler cmdDotEnabled ifFalse: [ ^ self ]. [ self processToInterrupt ifNotNil: [ :proc | proc debugWithTitle: 'User Interrupt' ] ifNil: [ UIManager default inform: 'Process not interruptable' ] "fork exceptions, we don't want interrupt handler to die" ] on: Error fork: [:ex | ex pass].
Cheers, Henry
-- Best regards, Igor Stasenko.
On 2 May 2013 16:39, Igor Stasenko <siguctua@gmail.com> wrote:
On 2 May 2013 15:33, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
On May 2, 2013, at 2:50 PM, Igor Stasenko wrote:
On 2 May 2013 09:54, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
What? I am 99.99% sure it used to interrupt the GUI process if no other viable candidate could be found, why change that? At least in my mind, if you hit cmd - dot, either you want to interrupt some process blocking the UI on a higher priority, or you want the UI process itself. For everything else, there's the Process Browser.
It was never like that. It was always looking for a process which is scheduled, but not interrupt process itself. usually that meant it interrupts things like finalization process, so i added logic to avoid interrupting it unless there's nothing else to interrupt.
From 1.4: handleUserInterrupt [|toInterrupt| toInterrupt := Processor preemptedProcess. "Only interrupt processes which are potentially blocking the UI" toInterrupt priority < UIManager default uiProcess priority ifTrue: [toInterrupt := Project uiProcess].
So yes, it was like that. (barring the other flaws you mentioned, about potentially interrupting critical high-priority processes)
Okay, then we need to change #ifNil clause in following method to just interrupt UI process, instead of showing useless "not interruptable" message:
handleUserInterrupt "This will be called from the event-fetcher process. Assume no system-vital processes have a lower priority than this, and are thus ok to interrupt" UserInterruptHandler cmdDotEnabled ifFalse: [ ^ self ].
[ self processToInterrupt ifNotNil: [ :proc | proc debugWithTitle: 'User Interrupt' ] ifNil: [ UIManager default inform: 'Process not interruptable' ]
"fork exceptions, we don't want interrupt handler to die" ] on: Error fork: [:ex | ex pass].
oh.. on second thought, even better.. processToInterrupt "look for best candidate to interrupt: first who is not weak-finalization process and only then weak-finalization process, if nothing left to interrupt. filter out the idle process, since killing it is fatal " | list | list := OrderedCollection new. Processor scanSchedule: [:p | "gather everything but idle process, and processes whose suspendedContext sender == nil, which usually means that process is only scheduled but had no chance to run" ((p ~~ Processor backgroundProcess) and: [ p suspendedContext sender notNil ]) ifTrue: [ list add: p ] ] startingAt: Processor activePriority. "now answer first process in list, skipping the finalization process" list do: [:p | p == WeakArray runningFinalizationProcess ifFalse: [ ^ p ] ]. "now answer first process , if any ,otherwise answer ui process by default" ^ list isEmpty ifTrue: [ UIManager default uiProcess ] ifFalse: [ list first ] so it interrupts even if i do 1 hour wait in workspace
Cheers, Henry
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On May 2, 2013, at 4:46 PM, Igor Stasenko wrote:
On 2 May 2013 16:39, Igor Stasenko <siguctua@gmail.com> wrote:
On 2 May 2013 15:33, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
On May 2, 2013, at 2:50 PM, Igor Stasenko wrote:
On 2 May 2013 09:54, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
What? I am 99.99% sure it used to interrupt the GUI process if no other viable candidate could be found, why change that? At least in my mind, if you hit cmd - dot, either you want to interrupt some process blocking the UI on a higher priority, or you want the UI process itself. For everything else, there's the Process Browser.
It was never like that. It was always looking for a process which is scheduled, but not interrupt process itself. usually that meant it interrupts things like finalization process, so i added logic to avoid interrupting it unless there's nothing else to interrupt.
From 1.4: handleUserInterrupt [|toInterrupt| toInterrupt := Processor preemptedProcess. "Only interrupt processes which are potentially blocking the UI" toInterrupt priority < UIManager default uiProcess priority ifTrue: [toInterrupt := Project uiProcess].
So yes, it was like that. (barring the other flaws you mentioned, about potentially interrupting critical high-priority processes)
Okay, then we need to change #ifNil clause in following method to just interrupt UI process, instead of showing useless "not interruptable" message:
handleUserInterrupt "This will be called from the event-fetcher process. Assume no system-vital processes have a lower priority than this, and are thus ok to interrupt" UserInterruptHandler cmdDotEnabled ifFalse: [ ^ self ].
[ self processToInterrupt ifNotNil: [ :proc | proc debugWithTitle: 'User Interrupt' ] ifNil: [ UIManager default inform: 'Process not interruptable' ]
"fork exceptions, we don't want interrupt handler to die" ] on: Error fork: [:ex | ex pass].
oh.. on second thought, even better..
processToInterrupt "look for best candidate to interrupt: first who is not weak-finalization process and only then weak-finalization process, if nothing left to interrupt.
filter out the idle process, since killing it is fatal " | list |
list := OrderedCollection new. Processor scanSchedule: [:p | "gather everything but idle process, and processes whose suspendedContext sender == nil, which usually means that process is only scheduled but had no chance to run"
((p ~~ Processor backgroundProcess) and: [ p suspendedContext sender notNil ]) ifTrue: [ list add: p ] ] startingAt: Processor activePriority.
"now answer first process in list, skipping the finalization process" list do: [:p | p == WeakArray runningFinalizationProcess ifFalse: [ ^ p ] ].
"now answer first process , if any ,otherwise answer ui process by default" ^ list isEmpty ifTrue: [ UIManager default uiProcess ] ifFalse: [ list first ]
so it interrupts even if i do
1 hour wait
in workspace Something like that yes, or maybe even: processToInterrupt "Look for best candidate to interrupt: - any scheduled non-finalization process of lower priority - the weak-finalization process, if scheduled - the UI process Never interrupt the idle process, since killing it is fatal"
| fallback | fallback := UIManager default uiProcess. Processor scanSchedule: [:p | "suspendedContext sender == nil usually means that process is only scheduled but had no chance to run" ((p ~~ Processor backgroundProcess) and: [ p suspendedContext sender notNil ifTrue: [ p ~~ WeakArray runningFinalizationProcess ifTrue: [^p] ifFalse: [fallback := p]] ] startingAt: Processor activePriority. ^fallback Cheers, Henry
On May 3, 2013, at 9:44 AM, Henrik Johansen wrote:
oh.. on second thought, even better..
processToInterrupt "look for best candidate to interrupt: first who is not weak-finalization process and only then weak-finalization process, if nothing left to interrupt.
filter out the idle process, since killing it is fatal " | list |
list := OrderedCollection new. Processor scanSchedule: [:p | "gather everything but idle process, and processes whose suspendedContext sender == nil, which usually means that process is only scheduled but had no chance to run"
((p ~~ Processor backgroundProcess) and: [ p suspendedContext sender notNil ]) ifTrue: [ list add: p ] ] startingAt: Processor activePriority.
"now answer first process in list, skipping the finalization process" list do: [:p | p == WeakArray runningFinalizationProcess ifFalse: [ ^ p ] ].
"now answer first process , if any ,otherwise answer ui process by default" ^ list isEmpty ifTrue: [ UIManager default uiProcess ] ifFalse: [ list first ]
so it interrupts even if i do
1 hour wait
in workspace Something like that yes, or maybe even: processToInterrupt "Look for best candidate to interrupt: - any scheduled non-finalization process of lower priority - the weak-finalization process, if scheduled - the UI process Never interrupt the idle process, since killing it is fatal"
| fallback |
fallback := UIManager default uiProcess. Processor scanSchedule: [:p | "suspendedContext sender == nil usually means that process is only scheduled but had no chance to run" ((p ~~ Processor backgroundProcess) and: [ p suspendedContext sender notNil ifTrue: [ p ~~ WeakArray runningFinalizationProcess ifTrue: [^p] ifFalse: [fallback := p]] ] startingAt: Processor activePriority. ^fallback
Cheers, Henry (That's just rewritten btw, functionality is the same)
Cheers, Henry
Sooooâ¦. I made a slice, but how does one save to the new inbox? You need credentials + some sort of access privileges all of a sudden? :S Cheers, Henry
On May 3, 2013, at 10:16 AM, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
Sooooâ¦. I made a slice, but how does one save to the new inbox? You need credentials + some sort of access privileges all of a sudden? :S
Yes, this is a temporary problem. Soon you can commit without being logged in. I added you for until this is done. Marcus
Well, add me as well please :-) 2013/5/3 Marcus Denker <marcus.denker@inria.fr>
On May 3, 2013, at 10:16 AM, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
Sooooâ¦. I made a slice, but how does one save to the new inbox? You need credentials + some sort of access privileges all of a sudden? :S
Yes, this is a temporary problem. Soon you can commit without being logged in.
I added you for until this is done.
Marcus
On May 3, 2013, at 12:05 PM, phil@highoctane.be wrote:
Well, add me as well please :-)
Done
2013/5/3 Marcus Denker <marcus.denker@inria.fr>
On May 3, 2013, at 10:16 AM, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
Sooooâ¦. I made a slice, but how does one save to the new inbox? You need credentials + some sort of access privileges all of a sudden? :S
Yes, this is a temporary problem. Soon you can commit without being logged in.
I added you for until this is done.
Marcus
On 3 May 2013 13:34, Marcus Denker <marcus.denker@inria.fr> wrote:
On May 3, 2013, at 12:05 PM, phil@highoctane.be wrote:
Well, add me as well please :-)
Done
and as i heard it is already integrated, yes?
2013/5/3 Marcus Denker <marcus.denker@inria.fr>
On May 3, 2013, at 10:16 AM, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
Sooooâ¦. I made a slice, but how does one save to the new inbox? You need credentials + some sort of access privileges all of a sudden? :S
Yes, this is a temporary problem. Soon you can commit without being logged in.
I added you for until this is done.
Marcus
-- Best regards, Igor Stasenko.
We had the same problem Alexandre Le 30 avr. 2013 à 16:44, Stéphane Ducasse <stephane.ducasse@inria.fr> a écrit :
trying to publish a slice on my harddisc without networkâ¦. and I could not interrupt anything. No cmd+. no interdiction sign did anything :(
So is it normal? Not being able to interrupt something is a pain.
stef
participants (9)
-
Alexandre Bergel -
Camillo Bruni -
Henrik Johansen -
Igor Stasenko -
Marcus Denker -
phil＠highoctane.be -
stephane ducasse -
Stéphane Ducasse -
Sven Van Caekenberghe