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
>>>>> [email protected]
>>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>>> 
>>>> 
>>>> _______________________________________________
>>>> Pharo-project mailing list
>>>> [email protected]
>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>> 
>>> _______________________________________________
>>> Pharo-project mailing list
>>> [email protected]
>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>> 
>> 
>> _______________________________________________
>> Pharo-project mailing list
>> [email protected]
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
> 
> 
> _______________________________________________
> Pharo-project mailing list
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project


_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Reply via email to