nspluginviewer priority on newer linux kernel

[Konrad Rzepecki]

Dnia czwartek, 16 sierpnia 2007, Thiago Macieira napisał(a):
> James Richard Tyrer wrote:
> >Yes, exactly.  The problem is that you need one process to send these
> >signals to the other process.  IIUC, listening at a socket doesn't
> >accomplish this.  That is to find out that the window doesn't have focus
> >and stop using the CPU.
>
> That would require a change to the NSPlugin API. The plugins themselves
> have to voluntarily stop what they are doing in a decent manner.
>
This haven't any chance to success. I don't see plugins voluntarily stop ( 
especially those closed source ).

> Imagine you have a file-uploader plugin and you're uploading a large file
> over a slow connection. You want to keep working while it uploads, so you
> want the plugin to keep running in the background, while you switch to
> other tabs and other programs.

I think the best solution is little modified my first idea. Nspluginviewer 
should run as normal process but not plugin specific threads. There should be 
a list of all threads and windows/widgets they are placed. Active window 
threads can have normal priority, threads which make some I/O low, and the 
rest lowest. Main thread can form time to time set required priorities 
according current focus and network traffic (plugin threads can set i.e. last 
I/O timestamp).

This is probably possible in KDE 4 ( QThread::setPriority exist since QT 4.1 ) 
for KDE 3.5.X I don't see any resonable solution (maybe ugly hack - direct 
call to pthread functions).

-- 
  Konrad Rzepecki (Hannibal)