nspluginviewer priority on newer linux kernel

[Thiago Macieira]

James Richard Tyrer wrote:
>>>> So I have idea, is possible to run plugins in active tab at nice 0
>>>> and others at 15? This should reduce slowdown to minimum and keep
>>>> cpu usage in resonable level.
>>>
>>> I have noticed a general problem with Konqueror "clogging up" when
>>> you open several windows and/or several tabs.  It appears to me that
>>> *only* the tab and/or window that has focus should be running.  Since
>>> the tabs in a window are all running under one process, we need
>>> cooperative multitasking here that works well.  The best would be if
>>> you had preemption so that other tabs or windows could load in the
>>> background but be instantly preempted when mouse (button press not
>>> just movement) or keyboard input occurs.
>>
>> Most CPU spend in khtml is for painting, so not for hidden tabs (at
>> least it shouldn't)
>
>That is what I said, 'it shouldn't'.

You are both agreeing that khtml isn't at fault here.

>Perhaps that is true (regarding khtml), but it isn't what was said.
>What was said is the nsplugins block Konqueror from running.  I have
>observed in using KSysGuard.

Understood. The problem is the nsplugin (running under nspluginviewer), 
not KHTML itself.

>> What nonsense is that? A X11 gui program nicely waits in 'select' or
>> 'poll'. Remember that the connection with the Xserver is a socket.
>> Just ideal to also monitor other socket connections.
>
>Which is what I said.  The socket is the place where the process listens
>for input.  The problem is that the process keeps running till it gets
>to that point.  What is needed is a way to improve listening so that you
>don't have to wait to generate input to the GUI.

You can't kill the nsplugin running in the background. You can't stop it 
completely either -- that could lead to undesired problems like network 
connections timing out due to inactivity.

On the other hand, renicing them to a lower value when they are in the 
background does sound like a good idea. As long as you can renice them up 
to a normal value when they come to the foreground.

I bet the plugins you are using are doing animations or other kinds of 
video -- that is, either they are timer-based or they are doing complex 
stuff. Or both.

If it's not, then it's just plain buggy software and you should report to 
the plugin author.

>>> You could improve this situation with multiple threads.  A small
>>> thread accepting the input and doing the GUI menus and controlling a
>>> large thread which actually does the work.  I have no idea how this
>>> would (or could) be implemented in C++ although I am sure I have a
>>> text somewhere that explains how to do it in a procedural language.
>>
>> More non-sense ..
>
>Yes, this is all nonsense.  <sarcasm> The problem doesn't exist so we
>shouldn't do anything about it.</sarcasm>

No sarcasm.

The problem might exist (I haven't tried 2.6.23), but the point is that 
threads would not solve the problem. The plugins are already run in a 
separate thread (actually, a whole separate process, but that's just one 
specific kind of thread).

Your suggestion of solution is the actual implementation right now.

-- 
  Thiago Macieira  -  thiago (AT) macieira.info - thiago (AT) kde.org
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20070816/8c7553a4/attachment.sig>