RE: background and forground process interaction

Hi Tor,
I was looking to see if something could be done at a level thich would
benefit the responsiveness of all of the task that are kicked of by
netbeans.
I appriciate that some of the tasks need to have specific code that
understands so logic to see if it should continue running, but I was
hoping that this could be done is a geneic manner, and be part of the
mechanism that tasks use.
 
I understand that there is some refactoring of the task that is occuring
in NB currently some that some of the tasks may be executed directly on
the AWT thread, that are lightweight task, so could 'heavyweight' tasks
be dispatched to a low priority thread and gain a methods to cancel,
then tasks that are based on the curent edit state of the source could
be cancelled when the source is changed (I know that this is not a
complete solution). These task could also be cancelled when the system
is overloaded
 
On my system (faster now, but still with some UI issues), there is only
one request processor. I dont know if that is the norm, and whether it
is configurable, but I suspect that the problem is that the parse
operation is stuck in front of the UI update in the queue and therefore
the UI is unresponsive. On the systems that I design I have multiple
executors, at various priorities to satisfy different classes of
operations. I am probably missing something but isnt that a relatively
simple solution atthe macro level to this problem. I appriciate that
this would require a chnage to the RequestProcessor, and the task
interfaces, and a mechanism to determine the priority of the task to be
executed, but these seem to provide no appriciable downside. Please feel
feee to re-educate me!

-----Original Message-----
From: Tor Norbye [mailto:[email protected]] 
Sent: Friday 7 November 2003 18:34
To: [email protected]
Subject: Re: [tasklist] background and forground process interaction


Sorry about the delay, just discovered this one:

Mike Skells wrote:


Hi, 
I have noticed that there several times while I am editing the
background process to do the parse(s) for the suggestions module kicks
in, when my cpu was already busy doing something else, e.g. code
completion, and the UI lags because of this 
 
I have a few ideas. I am not sure that these are issues for this
tasklist, or general NB issues 
 
1. when an action is an intensive application, such as the code parse
for the suggestion module, pmd etc, and the action is kicked of
automatically then could the priority be lowered

 
2. could the varios suggestion providers affect the scheduling of each
other, e.g an option so that only run PMD iff there are no compiler
errors.


It already attempts to do this. While it can't cancel a PMD run in the
middle, if a user edit comes in while it's running through the
suggestion provider list, it will abort/skip out of the loop so that the
remaining suggestion providers are not run.
[Mike Skells] It seem to kick straight back in to the next run,
otherwise the propblems that I mensioned would not happen. I get 
....unrecognised symbol t 
....unrecognised symbol to
....unrecognised symbol toS
....unrecognised symbol toSt
....unrecognised symbol toStr



etc 


 
3. could the suggestion providers detect user activity and stop their
current run (sometimes I get several code warnings about the same word
that I am typing, each with one morecharacter typed than the last! When
the happens the UI is really slow. As a non touch typist I dont usually
get 2 words ahead of the UI! (yes I do have a slow machine...)


If you're on a slow machine, you probably want the suggestion providers
run at file open/save time instead of open/edit time. You can customize
this; right click in the suggestions window - one of the options there
let you change it.
[Mike Skells] I am looking for a fix to the problem without a loss in
functionallity. Some people call me a purist / optimist / ... ;) 

-- Tor