User interrupt does not always break UI process
Locked
User interrupt does not always break UI process
 
|
I often get the Finalization process when I press Cmd-.
Usually I want the UI process. But it should be possible to break into a higher-level one too, if it takes much time. Not sure if this could be made more intelligent? - Bert - |
Re: User interrupt does not always break UI process
|
|
On Thu, Jun 23, 2011 at 04:26:41PM +0200, Bert Freudenberg wrote:
> I often get the Finalization process when I press Cmd-. > > Usually I want the UI process. But it should be possible to break into > a higher-level one too, if it takes much time. Not sure if this could > be made more intelligent? It's a bit of a tricky problem. The interrupt key gets noticed by the VM, which signals the FinalizationSemaphore, which gets noticed by the finalizationProcess, which needs to figure out what process was the likely cause of the user hitting the interrupt key. It's not necessarily the UI process, because the problem may have originated from e.g. "[Smalltalk createStackOverflow] fork". To me, the more interesting part of the problem is the fact that the finalization process is frequently being selected as the process that the user was "probably trying to interrupt". That means that the finalization process is consuming so much processor resource that it get interrupted instead of the actual process that the user intended to interrupt with the Cmd-. key. This seems to be typical of images that have accumulated a lot of use and that tend to get sluggish over a long period of time. It suggests some opportunity to improve the weak finalization process overall. This is not a trivial problem by any means, and it has been discussed before, but if I'm interpreting this correctly it might be better to put some effort into trying to improve this, as opposed to trying to make the user interrupt handler be smart enough to avoid interrupting the finalizationProcess. In terms of near-term improvements that might be possible, perhaps it would help to have tools to reduce the amount of cruft that the finalizationProcess needs to deal with. Various weak references seem to accumulate over time, probably for no good reason, and eventually this seems to lead to sluggish images and heavy loads on the finalizationProcess. - Dave |
Re: User interrupt does not always break UI process
|
|
On 24.06.2011, at 05:20, David T. Lewis wrote: > On Thu, Jun 23, 2011 at 04:26:41PM +0200, Bert Freudenberg wrote: >> I often get the Finalization process when I press Cmd-. >> >> Usually I want the UI process. But it should be possible to break into >> a higher-level one too, if it takes much time. Not sure if this could >> be made more intelligent? > > It's a bit of a tricky problem. The interrupt key gets noticed by the > VM, which signals the FinalizationSemaphore, which gets noticed by the > finalizationProcess, which needs to figure out what process was the > likely cause of the user hitting the interrupt key. It's not necessarily > the UI process, because the problem may have originated from e.g. > "[Smalltalk createStackOverflow] fork". I think you mean the InterruptSemaphore, waking up the userInterruptWatcher process. > To me, the more interesting part of the problem is the fact that the > finalization process is frequently being selected as the process that > the user was "probably trying to interrupt". That means that the > finalization process is consuming so much processor resource that > it get interrupted instead of the actual process that the user intended > to interrupt with the Cmd-. key. > > This seems to be typical of images that have accumulated a lot of > use and that tend to get sluggish over a long period of time. It > suggests some opportunity to improve the weak finalization process > overall. This is not a trivial problem by any means, and it has > been discussed before, but if I'm interpreting this correctly it > might be better to put some effort into trying to improve this, > as opposed to trying to make the user interrupt handler be smart > enough to avoid interrupting the finalizationProcess. > > In terms of near-term improvements that might be possible, perhaps > it would help to have tools to reduce the amount of cruft that the > finalizationProcess needs to deal with. Various weak references > seem to accumulate over time, probably for no good reason, and > eventually this seems to lead to sluggish images and heavy loads > on the finalizationProcess. > > - Dave In my case I don't want it to ever interrupt the higher-priority "system" processes (event tickler, low space watcher, finalizer), but the "last" user process. Not quite sure how to determine that, though. Crazy idea: On user interrupt, sample the system for 100 ms to see which process takes up so much time. Too crazy? ;) - Bert - |
Re: User interrupt does not always break UI process
|
|
> In my case I don't want it to ever interrupt the higher-priority "system" processes (event tickler, low space watcher, finalizer), but the "last" user process. Not quite sure how to determine that, though.
> > Crazy idea: On user interrupt, sample the system for 100 ms to see which process takes up so much time. Too crazy? ;) But, IIUC, wouldn't such a sample would probably lead to the same answer (e.g., the finalization process), if that is the process that is consuming a lot at that moment..? I don't quite remember the status of Igor's finalization enhancement in the image and VM - a simple pointer swap was able to take the place of full-enumeration of the finalization list. My gut tells me the support is in the Cog VM but that there might be some concurrent access issues on the image side.. |
Re: User interrupt does not always break UI process
|
|
In reply to this post by Bert Freudenberg
On Thu, Jun 23, 2011 at 7:26 AM, Bert Freudenberg <[hidden email]> wrote: -- I often get the Finalization process when I press Cmd-. Seems to me that the code could check if the interrupted process was one of the system processes not to be interrupted then a different process could be chosen to interrupt. The list of processes in ProcessBrowser class>>registerWellKnownProcesses already has an allowStop accessor that seems to capture the desired intent.
So let's say that at least some of the list of well known processes gets moved to ProcessorScheduler and is consulted by ProcessorScheduler>>preemptedProcess to filter-out processes that should not be stopped by the user interrupt.
Bert, I could take a tilt at this and at the same time add the Qwaq code for the Cog VM's processpreemptionYields switch, which makes the VM behave like the VisualWorks VM such that preempting a process doesn't put it to the back of its run queue (an implicit yield) which is a much safer scheduling policy than the blue books. And note that this is optional, but if in effect it does mean that preemptedProcess should interrupt the /first/ process on the relevant runnable list, not the /last/ :)
- Bert - best, Eliot |
Re: User interrupt does not always break UI process
|
|
In reply to this post by Bert Freudenberg
On Fri, Jun 24, 2011 at 03:32:21PM +0200, Bert Freudenberg wrote:
> > On 24.06.2011, at 05:20, David T. Lewis wrote: > > > On Thu, Jun 23, 2011 at 04:26:41PM +0200, Bert Freudenberg wrote: > >> I often get the Finalization process when I press Cmd-. > >> > >> Usually I want the UI process. But it should be possible to break into > >> a higher-level one too, if it takes much time. Not sure if this could > >> be made more intelligent? > > > > It's a bit of a tricky problem. The interrupt key gets noticed by the > > VM, which signals the FinalizationSemaphore, which gets noticed by the > > finalizationProcess, which needs to figure out what process was the > > likely cause of the user hitting the interrupt key. It's not necessarily > > the UI process, because the problem may have originated from e.g. > > "[Smalltalk createStackOverflow] fork". > > I think you mean the InterruptSemaphore, waking up the userInterruptWatcher process. > > > To me, the more interesting part of the problem is the fact that the > > finalization process is frequently being selected as the process that > > the user was "probably trying to interrupt". That means that the > > finalization process is consuming so much processor resource that > > it get interrupted instead of the actual process that the user intended > > to interrupt with the Cmd-. key. > > > > This seems to be typical of images that have accumulated a lot of > > use and that tend to get sluggish over a long period of time. It > > suggests some opportunity to improve the weak finalization process > > overall. This is not a trivial problem by any means, and it has > > been discussed before, but if I'm interpreting this correctly it > > might be better to put some effort into trying to improve this, > > as opposed to trying to make the user interrupt handler be smart > > enough to avoid interrupting the finalizationProcess. > > > > In terms of near-term improvements that might be possible, perhaps > > it would help to have tools to reduce the amount of cruft that the > > finalizationProcess needs to deal with. Various weak references > > seem to accumulate over time, probably for no good reason, and > > eventually this seems to lead to sluggish images and heavy loads > > on the finalizationProcess. > > > > - Dave > > In my case I don't want it to ever interrupt the higher-priority "system" processes (event tickler, low space watcher, finalizer), but the "last" user process. Not quite sure how to determine that, though. > > Crazy idea: On user interrupt, sample the system for 100 ms to see which process takes up so much time. Too crazy? ;) Not crazy at all. From the user point of view it takes hundreds of milliseconds to respond to the interrupt key anyway. So pausing for another 100 ms to figure out what process is currently hogging the system would be a perfectly reasonable thing to do. On the other hand, you might just find out that the finalizationProcess is still the process that gets interrupted. I note that the finalization process runs at a higher priority than user processes, including the UI process. So if you had a runaway UI process and also a busy finalization process, I would expect the finalization process to be grabbing more of the processor and thus likely to be selected in response to the interrupt key. But I think something else may be going on here. If I modify my finalization process to ensure that it is spending most of its time waiting, I still find that it takes two interrupt key presses to interrupt a createStackOverflow. In other words, the finalization process is always being interrupted first, even if it is not busy doing anything most of the time. Dave |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |