[Pharo-project] Should I be able to hang my pharo 1.1 image so easily?
Hi guys - it seems really easy to hang my seaside image and then have to force quit and restart. I thought that cmd-. was supposed to recover, but it never seems to work for me. Am I doing something wrong? (I am using a pharo 1.1 seaside3.0rc3 image with the mac 4.2.5 vm). I had the following code: modelUpdate self pusher javascript: [ :jsScript | jsScript << (self generateUpdateScriptWith: jsScript) ] generateUpdateScriptWith: jsScript ^aJScript goto: anActionUrl withoutQuery I think that the << operator is adding something that has already been added via aJScript goto: - and so its recursive. Anyway - when I hit this with my browser - the cpu of my Pharo image goes to 99% and I can hit Cmd-. all I want, but eventually it just dies - or I have to do a force quit. Should it be so easy to kill an image like this? Tim
On Aug 17, 2010, at 2:05 11PM, TimM wrote:
Hi guys - it seems really easy to hang my seaside image and then have to force quit and restart. I thought that cmd-. was supposed to recover, but it never seems to work for me.
Am I doing something wrong? (I am using a pharo 1.1 seaside3.0rc3 image with the mac 4.2.5 vm).
I had the following code:
modelUpdate self pusher javascript: [ :jsScript | jsScript << (self generateUpdateScriptWith: jsScript) ]
generateUpdateScriptWith: jsScript
^aJScript goto: anActionUrl withoutQuery
I think that the << operator is adding something that has already been added via aJScript goto: - and so its recursive.
Anyway - when I hit this with my browser - the cpu of my Pharo image goes to 99% and I can hit Cmd-. all I want, but eventually it just dies - or I have to do a force quit.
Should it be so easy to kill an image like this?
Tim
Is this code run in a separate process? UserInterruptHandler>>handleUserInterrupt specifically interrupts the UI-process, rather than f.ex. the last process consuming cycles. Whether that is desired behaviour or not, is up for discussion :) Cheers, Henry
Henrik Johansen wrote:
Is this code run in a separate process? UserInterruptHandler>>handleUserInterrupt specifically interrupts the UI-process, rather than f.ex. the last process consuming cycles. Whether that is desired behaviour or not, is up for discussion :)
I'm not sure - as its seaside is that a UI-process (I don't think it is). By browser - I mean web browser. And then I notice my cpu spike and if I switch back to squeak, its hosed. Tim
On Aug 17, 2010, at 3:38 20PM, TimM wrote:
Henrik Johansen wrote:
Is this code run in a separate process? UserInterruptHandler>>handleUserInterrupt specifically interrupts the UI-process, rather than f.ex. the last process consuming cycles. Whether that is desired behaviour or not, is up for discussion :)
I'm not sure - as its seaside is that a UI-process (I don't think it is). By browser - I mean web browser. And then I notice my cpu spike and if I switch back to squeak, its hosed.
Tim There's only one UI Process (tm) in Pharo/Squeak, responsible for updating the UI, running doits, etc.
Not quite sure how Seaside does its magic when requests are coming in, but if it forks of their processing with priority >= UIProcess priority, it will indeed "hose" the image with no means of recovering using Cmd-dot in the case of an infinite loop. Try the following from a workspace to illustrate: "Interruptable with Cmd-dot" [true ] whileTrue. "Forking at lower than UI process, so UI stays responsive, but does not interrupt runaway process with Cmd-dot (you can terminate it using process browser)" [[true ] whileTrue] forkAt: Processor activePriority - 1 "Code run from a workspace will run in the UI process, so active priority will be the UI process priority" "Forking at same as UI process, Cmd-dot interrups UI process rather than runaway, but debugger is (almost) never displayed since runaway process takes almost all cycles" [[true] whileTrue] fork "Fork forks of the process at same priority as active process" Cheers, Henry
I think I have the same problem. It does not actually jam the image right away but makes it really slow which renders it unusable. After a while memory runs out and it crashes. Have not seen this many times thou. It would help if there was a key sequence which would suspend other than UI process. -- Panu
thanks for reporting that. do you have a case that we could reproduce or have an image people could access? Stef On Aug 17, 2010, at 8:30 PM, Panu Suominen wrote:
I think I have the same problem. It does not actually jam the image right away but makes it really slow which renders it unusable. After a while memory runs out and it crashes. Have not seen this many times thou. It would help if there was a key sequence which would suspend other than UI process.
-- Panu
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 17.08.2010 21:04, Stéphane Ducasse wrote:
thanks for reporting that. do you have a case that we could reproduce or have an image people could access?
Stef
On Aug 17, 2010, at 8:30 PM, Panu Suominen wrote:
I think I have the same problem. It does not actually jam the image right away but makes it really slow which renders it unusable. After a while memory runs out and it crashes. Have not seen this many times thou. It would help if there was a key sequence which would suspend other than UI process.
-- Panu
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project See my examples, the last one reproduces it.
Cheers, Henry
Hello all, The answer in general is "no." The only caveat with Seaside code is that (I gues due to continuations??), it is possible to make simple mistakes with harsh consequences. My early attempts at Seaside programming were not pretty; with two books now available, it should be easier to start out knowing not to render in callbacks and vice versa. Is the Seaside code in this case poorly-behaved? Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Stéphane Ducasse Sent: Tuesday, August 17, 2010 2:04 PM To: Pharo-project@lists.gforge.inria.fr; panu.suominen@iki.fi Subject: Re: [Pharo-project] Should I be able to hang my pharo 1.1 image so easily? thanks for reporting that. do you have a case that we could reproduce or have an image people could access? Stef On Aug 17, 2010, at 8:30 PM, Panu Suominen wrote:
I think I have the same problem. It does not actually jam the image right away but makes it really slow which renders it unusable. After a while memory runs out and it crashes. Have not seen this many times thou. It would help if there was a key sequence which would suspend other than UI process.
-- Panu
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 17 August 2010 23:36, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Hello all,
The answer in general is "no." Â The only caveat with Seaside code is that (I gues due to continuations??), it is possible to make simple mistakes with harsh consequences. Â My early attempts at Seaside programming were not pretty; with two books now available, it should be easier to start out knowing not to render in callbacks and vice versa.
Is the Seaside code in this case poorly-behaved?
Seaside doesn't use continuations anymore, unless you have a WATask. Continuations do not affect the interrupt behavior. Lukas -- Lukas Renggli www.lukas-renggli.ch
Lukas, Interesting! How do I get rid of my tasks then, traits?? Bill -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Tuesday, August 17, 2010 4:53 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Should I be able to hang my pharo 1.1 image so easily? On 17 August 2010 23:36, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Hello all,
The answer in general is "no." Â The only caveat with Seaside code is that (I gues due to continuations??), it is possible to make simple mistakes with harsh consequences. Â My early attempts at Seaside programming were not pretty; with two books now available, it should be easier to start out knowing not to render in callbacks and vice versa.
Is the Seaside code in this case poorly-behaved?
Seaside doesn't use continuations anymore, unless you have a WATask. Continuations do not affect the interrupt behavior. Lukas -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 18 August 2010 00:06, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Lukas,
Interesting! Â How do I get rid of my tasks then, traits??
Uhh? That has nothing to do with traits. http://book.seaside.st/book/components/calling/show-answer Lukas
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Tuesday, August 17, 2010 4:53 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Should I be able to hang my pharo 1.1 image so easily?
On 17 August 2010 23:36, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Hello all,
The answer in general is "no." Â The only caveat with Seaside code is that (I gues due to continuations??), it is possible to make simple mistakes with harsh consequences. Â My early attempts at Seaside programming were not pretty; with two books now available, it should be easier to start out knowing not to render in callbacks and vice versa.
Is the Seaside code in this case poorly-behaved?
Seaside doesn't use continuations anymore, unless you have a WATask.
Continuations do not affect the interrupt behavior.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
You're wrong about "nothing to do with..." I am referring to coding idioms that might replace tasks; traits are almost certainly one method. That said, I will take a look at show/answer as a possible replacement. -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Tuesday, August 17, 2010 5:11 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Should I be able to hang my pharo 1.1 image so easily? On 18 August 2010 00:06, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Lukas,
Interesting! Â How do I get rid of my tasks then, traits??
Uhh? That has nothing to do with traits. http://book.seaside.st/book/components/calling/show-answer Lukas
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Tuesday, August 17, 2010 4:53 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Should I be able to hang my pharo 1.1 image so easily?
On 17 August 2010 23:36, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Hello all,
The answer in general is "no." Â The only caveat with Seaside code is that (I gues due to continuations??), it is possible to make simple mistakes with harsh consequences. Â My early attempts at Seaside programming were not pretty; with two books now available, it should be easier to start out knowing not to render in callbacks and vice versa.
Is the Seaside code in this case poorly-behaved?
Seaside doesn't use continuations anymore, unless you have a WATask.
Continuations do not affect the interrupt behavior.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On 18 August 2010 00:22, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
You're wrong about "nothing to do with..." Â I am referring to coding idioms that might replace tasks; traits are almost certainly one method. Â That said, I will take a look at show/answer as a possible replacement.
- Traits are about code sharing. - Tasks are about modeling flow. There is really nothing common to these two things. This is getting off-topic though. The issue with the not-working interrupt key in Pharo is serious. Lukas
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Tuesday, August 17, 2010 5:11 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Should I be able to hang my pharo 1.1 image so easily?
On 18 August 2010 00:06, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Lukas,
Interesting! Â How do I get rid of my tasks then, traits??
Uhh? That has nothing to do with traits.
http://book.seaside.st/book/components/calling/show-answer
Lukas
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Tuesday, August 17, 2010 4:53 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Should I be able to hang my pharo 1.1 image so easily?
On 17 August 2010 23:36, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Hello all,
The answer in general is "no." Â The only caveat with Seaside code is that (I gues due to continuations??), it is possible to make simple mistakes with harsh consequences. Â My early attempts at Seaside programming were not pretty; with two books now available, it should be easier to start out knowing not to render in callbacks and vice versa.
Is the Seaside code in this case poorly-behaved?
Seaside doesn't use continuations anymore, unless you have a WATask.
Continuations do not affect the interrupt behavior.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
The two can indeed be related. The question is how one goes about modeling flow; one approach could be to share an algorithm and traits might make that sufficiently simple to justify ditching something that is using continuations (which I have never liked). -----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Tuesday, August 17, 2010 5:26 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Should I be able to hang my pharo 1.1 image so easily? On 18 August 2010 00:22, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
You're wrong about "nothing to do with..." Â I am referring to coding idioms that might replace tasks; traits are almost certainly one method. Â That said, I will take a look at show/answer as a possible replacement.
- Traits are about code sharing. - Tasks are about modeling flow. There is really nothing common to these two things. This is getting off-topic though. The issue with the not-working interrupt key in Pharo is serious. Lukas
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Tuesday, August 17, 2010 5:11 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Should I be able to hang my pharo 1.1 image so easily?
On 18 August 2010 00:06, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Lukas,
Interesting! Â How do I get rid of my tasks then, traits??
Uhh? That has nothing to do with traits.
http://book.seaside.st/book/components/calling/show-answer
Lukas
Bill
-----Original Message----- From: pharo-project-bounces@lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lukas Renggli Sent: Tuesday, August 17, 2010 4:53 PM To: Pharo-project@lists.gforge.inria.fr Subject: Re: [Pharo-project] Should I be able to hang my pharo 1.1 image so easily?
On 17 August 2010 23:36, Schwab,Wilhelm K <bschwab@anest.ufl.edu> wrote:
Hello all,
The answer in general is "no." Â The only caveat with Seaside code is that (I gues due to continuations??), it is possible to make simple mistakes with harsh consequences. Â My early attempts at Seaside programming were not pretty; with two books now available, it should be easier to start out knowing not to render in callbacks and vice versa.
Is the Seaside code in this case poorly-behaved?
Seaside doesn't use continuations anymore, unless you have a WATask.
Continuations do not affect the interrupt behavior.
Lukas
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I heard about that problem too... In Squeak 3.9 I can interrupt [[true] whileTrue] fork, but not in Pharo. Has anybody an idea why this doesn't work anymore? Adrian On Aug 17, 2010, at 16:27 , Henrik Johansen wrote:
On Aug 17, 2010, at 3:38 20PM, TimM wrote:
Henrik Johansen wrote:
Is this code run in a separate process? UserInterruptHandler>>handleUserInterrupt specifically interrupts the UI-process, rather than f.ex. the last process consuming cycles. Whether that is desired behaviour or not, is up for discussion :)
I'm not sure - as its seaside is that a UI-process (I don't think it is). By browser - I mean web browser. And then I notice my cpu spike and if I switch back to squeak, its hosed.
Tim There's only one UI Process (tm) in Pharo/Squeak, responsible for updating the UI, running doits, etc.
Not quite sure how Seaside does its magic when requests are coming in, but if it forks of their processing with priority >= UIProcess priority, it will indeed "hose" the image with no means of recovering using Cmd-dot in the case of an infinite loop.
Try the following from a workspace to illustrate:
"Interruptable with Cmd-dot" [true ] whileTrue.
"Forking at lower than UI process, so UI stays responsive, but does not interrupt runaway process with Cmd-dot (you can terminate it using process browser)" [[true ] whileTrue] forkAt: Processor activePriority - 1 "Code run from a workspace will run in the UI process, so active priority will be the UI process priority"
"Forking at same as UI process, Cmd-dot interrups UI process rather than runaway, but debugger is (almost) never displayed since runaway process takes almost all cycles" [[true] whileTrue] fork "Fork forks of the process at same priority as active process"
Cheers, Henry _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Probably completely off the mark but just in case it jogs someone's memory, the fixes for this issue that went into Squeak 3.9 were tracked on Mantis here: http://bugs.squeak.org/view.php?id=1041 Possibly one of the patches got undone by accident? HTH, Dave On Tue, Aug 17, 2010 at 10:28:31PM +0200, Adrian Lienhard wrote:
I heard about that problem too...
In Squeak 3.9 I can interrupt [[true] whileTrue] fork, but not in Pharo.
Has anybody an idea why this doesn't work anymore?
Adrian
On Aug 17, 2010, at 16:27 , Henrik Johansen wrote:
On Aug 17, 2010, at 3:38 20PM, TimM wrote:
Henrik Johansen wrote:
Is this code run in a separate process? UserInterruptHandler>>handleUserInterrupt specifically interrupts the UI-process, rather than f.ex. the last process consuming cycles. Whether that is desired behaviour or not, is up for discussion :)
I'm not sure - as its seaside is that a UI-process (I don't think it is). By browser - I mean web browser. And then I notice my cpu spike and if I switch back to squeak, its hosed.
Tim There's only one UI Process (tm) in Pharo/Squeak, responsible for updating the UI, running doits, etc.
Not quite sure how Seaside does its magic when requests are coming in, but if it forks of their processing with priority >= UIProcess priority, it will indeed "hose" the image with no means of recovering using Cmd-dot in the case of an infinite loop.
Try the following from a workspace to illustrate:
"Interruptable with Cmd-dot" [true ] whileTrue.
"Forking at lower than UI process, so UI stays responsive, but does not interrupt runaway process with Cmd-dot (you can terminate it using process browser)" [[true ] whileTrue] forkAt: Processor activePriority - 1 "Code run from a workspace will run in the UI process, so active priority will be the UI process priority"
"Forking at same as UI process, Cmd-dot interrups UI process rather than runaway, but debugger is (almost) never displayed since runaway process takes almost all cycles" [[true] whileTrue] fork "Fork forks of the process at same priority as active process"
Cheers, Henry _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
thanks david for the pointer. Yes we should investigate that again. On Aug 18, 2010, at 3:20 AM, David T. Lewis wrote:
Probably completely off the mark but just in case it jogs someone's memory, the fixes for this issue that went into Squeak 3.9 were tracked on Mantis here:
http://bugs.squeak.org/view.php?id=1041
Possibly one of the patches got undone by accident?
HTH, Dave
On Tue, Aug 17, 2010 at 10:28:31PM +0200, Adrian Lienhard wrote:
I heard about that problem too...
In Squeak 3.9 I can interrupt [[true] whileTrue] fork, but not in Pharo.
Has anybody an idea why this doesn't work anymore?
Adrian
On Aug 17, 2010, at 16:27 , Henrik Johansen wrote:
On Aug 17, 2010, at 3:38 20PM, TimM wrote:
Henrik Johansen wrote:
Is this code run in a separate process? UserInterruptHandler>>handleUserInterrupt specifically interrupts the UI-process, rather than f.ex. the last process consuming cycles. Whether that is desired behaviour or not, is up for discussion :)
I'm not sure - as its seaside is that a UI-process (I don't think it is). By browser - I mean web browser. And then I notice my cpu spike and if I switch back to squeak, its hosed.
Tim There's only one UI Process (tm) in Pharo/Squeak, responsible for updating the UI, running doits, etc.
Not quite sure how Seaside does its magic when requests are coming in, but if it forks of their processing with priority >= UIProcess priority, it will indeed "hose" the image with no means of recovering using Cmd-dot in the case of an infinite loop.
Try the following from a workspace to illustrate:
"Interruptable with Cmd-dot" [true ] whileTrue.
"Forking at lower than UI process, so UI stays responsive, but does not interrupt runaway process with Cmd-dot (you can terminate it using process browser)" [[true ] whileTrue] forkAt: Processor activePriority - 1 "Code run from a workspace will run in the UI process, so active priority will be the UI process priority"
"Forking at same as UI process, Cmd-dot interrups UI process rather than runaway, but debugger is (almost) never displayed since runaway process takes almost all cycles" [[true] whileTrue] fork "Fork forks of the process at same priority as active process"
Cheers, Henry _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I've submitted a slice to inbox, which contains a proposed fix. Details in the issue (2825) for those interested. Cheers, Henry On Aug 18, 2010, at 9:25 52AM, Stéphane Ducasse wrote:
thanks david for the pointer. Yes we should investigate that again.
On Aug 18, 2010, at 3:20 AM, David T. Lewis wrote:
Probably completely off the mark but just in case it jogs someone's memory, the fixes for this issue that went into Squeak 3.9 were tracked on Mantis here:
http://bugs.squeak.org/view.php?id=1041
Possibly one of the patches got undone by accident?
HTH, Dave
On Tue, Aug 17, 2010 at 10:28:31PM +0200, Adrian Lienhard wrote:
I heard about that problem too...
In Squeak 3.9 I can interrupt [[true] whileTrue] fork, but not in Pharo.
Has anybody an idea why this doesn't work anymore?
Adrian
On Aug 17, 2010, at 16:27 , Henrik Johansen wrote:
On Aug 17, 2010, at 3:38 20PM, TimM wrote:
Henrik Johansen wrote:
Is this code run in a separate process? UserInterruptHandler>>handleUserInterrupt specifically interrupts the UI-process, rather than f.ex. the last process consuming cycles. Whether that is desired behaviour or not, is up for discussion :)
I'm not sure - as its seaside is that a UI-process (I don't think it is). By browser - I mean web browser. And then I notice my cpu spike and if I switch back to squeak, its hosed.
Tim There's only one UI Process (tm) in Pharo/Squeak, responsible for updating the UI, running doits, etc.
Not quite sure how Seaside does its magic when requests are coming in, but if it forks of their processing with priority >= UIProcess priority, it will indeed "hose" the image with no means of recovering using Cmd-dot in the case of an infinite loop.
Try the following from a workspace to illustrate:
"Interruptable with Cmd-dot" [true ] whileTrue.
"Forking at lower than UI process, so UI stays responsive, but does not interrupt runaway process with Cmd-dot (you can terminate it using process browser)" [[true ] whileTrue] forkAt: Processor activePriority - 1 "Code run from a workspace will run in the UI process, so active priority will be the UI process priority"
"Forking at same as UI process, Cmd-dot interrups UI process rather than runaway, but debugger is (almost) never displayed since runaway process takes almost all cycles" [[true] whileTrue] fork "Fork forks of the process at same priority as active process"
Cheers, Henry _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
TX! On Aug 18, 2010, at 4:29 PM, Henrik Johansen wrote:
I've submitted a slice to inbox, which contains a proposed fix. Details in the issue (2825) for those interested.
Cheers, Henry
On Aug 18, 2010, at 9:25 52AM, Stéphane Ducasse wrote:
thanks david for the pointer. Yes we should investigate that again.
On Aug 18, 2010, at 3:20 AM, David T. Lewis wrote:
Probably completely off the mark but just in case it jogs someone's memory, the fixes for this issue that went into Squeak 3.9 were tracked on Mantis here:
http://bugs.squeak.org/view.php?id=1041
Possibly one of the patches got undone by accident?
HTH, Dave
On Tue, Aug 17, 2010 at 10:28:31PM +0200, Adrian Lienhard wrote:
I heard about that problem too...
In Squeak 3.9 I can interrupt [[true] whileTrue] fork, but not in Pharo.
Has anybody an idea why this doesn't work anymore?
Adrian
On Aug 17, 2010, at 16:27 , Henrik Johansen wrote:
On Aug 17, 2010, at 3:38 20PM, TimM wrote:
Henrik Johansen wrote:
Is this code run in a separate process? UserInterruptHandler>>handleUserInterrupt specifically interrupts the UI-process, rather than f.ex. the last process consuming cycles. Whether that is desired behaviour or not, is up for discussion :)
I'm not sure - as its seaside is that a UI-process (I don't think it is). By browser - I mean web browser. And then I notice my cpu spike and if I switch back to squeak, its hosed.
Tim There's only one UI Process (tm) in Pharo/Squeak, responsible for updating the UI, running doits, etc.
Not quite sure how Seaside does its magic when requests are coming in, but if it forks of their processing with priority >= UIProcess priority, it will indeed "hose" the image with no means of recovering using Cmd-dot in the case of an infinite loop.
Try the following from a workspace to illustrate:
"Interruptable with Cmd-dot" [true ] whileTrue.
"Forking at lower than UI process, so UI stays responsive, but does not interrupt runaway process with Cmd-dot (you can terminate it using process browser)" [[true ] whileTrue] forkAt: Processor activePriority - 1 "Code run from a workspace will run in the UI process, so active priority will be the UI process priority"
"Forking at same as UI process, Cmd-dot interrups UI process rather than runaway, but debugger is (almost) never displayed since runaway process takes almost all cycles" [[true] whileTrue] fork "Fork forks of the process at same priority as active process"
Cheers, Henry _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (9)
-
Adrian Lienhard -
David T. Lewis -
Henrik Johansen -
Henrik Sperre Johansen
-
Lukas Renggli -
Panu Suominen -
Schwab,Wilhelm K -
Stéphane Ducasse -
TimM