Preventing scripts blocking Amarok - any taker?

[Bart Cerneels]

On Thu, Dec 16, 2010 at 15:02, Mark Kretschmann <kretschmann at kde.org> wrote:
> On Thu, Dec 16, 2010 at 2:48 PM, Bart Cerneels <bart.cerneels at kde.org> wrote:
>> On Thu, Dec 16, 2010 at 14:20, Mark Kretschmann <kretschmann at kde.org> wrote:
>>> On Thu, Dec 16, 2010 at 2:17 PM, Bart Cerneels <bart.cerneels at kde.org> wrote:
>>>> On Thu, Dec 16, 2010 at 13:59, Mark Kretschmann <kretschmann at kde.org> wrote:
>>>>> On Thu, Dec 16, 2010 at 12:22 PM, Myriam Schweingruber <myriam at kde.org> wrote:
>>>>>> Hi all,
>>>>>>
>>>>>> it happens sometimes that a 3rd-party script is running wild and
>>>>>> blocks Amarok. Mark already started to write a mockup checking if a
>>>>>> script takes too long that should suggest killing it when it stalls.
>>>>>> The string already is prepared here:
>>>>>>
>>>>>> src/dialogs/ScriptManager.cpp line 609
>>>>>>
>>>>>> //MOCKUP method, see API docs
>>>>>> void
>>>>>> ScriptManager::showScriptStalledDialog()  // SLOT
>>>>>> {
>>>>>>    const QString script = "FIXME";
>>>>>>
>>>>>>    const int reply = KMessageBox::questionYesNo( 0, i18n( "The script
>>>>>> '%1' appears to have stalled.\n\n"
>>>>>>                                                           "Would you
>>>>>> like to stop it?", script ),
>>>>>>                                                           i18n(
>>>>>> "Script Manager - Amarok" ),
>>>>>>
>>>>>> KStandardGuiItem::yes(),
>>>>>>
>>>>>> KStandardGuiItem::no(),
>>>>>>                                                           QString(),
>>>>>>
>>>>>> KMessageBox::Dangerous );
>>>>>>    Q_UNUSED(reply)
>>>>>> }
>>>>>>
>>>>>>
>>>>>> Mark being very busy at the moment with his day job it would be nice
>>>>>> if somebody could give this the final push. The string is already in,
>>>>>> so this would not cause a string change and can still be committed for
>>>>>> 2.4
>>>>>
>>>>> My original idea for solving this was the following:
>>>>>
>>>>> We start a "watchdog" thread that checks regularly if the GUI blocks.
>>>>> I'm not quite sure how to check this, but it should be possible. And
>>>>> if we detect that it is blocking in a script, we kill that script.
>>>>>
>>>>> I dunno if the idea is too simplistic, or if it might work. But the
>>>>> "watchdog" thread is probably needed, I guess.
>>>>
>>>> Have the mainloop update a counter. If counter == counter_previous:
>>>> warning dialog.
>>>
>>> Right, that could work.
>>>
>>> More difficult: Actually "killing" the script. They are running in-process...
>>>
>>
>> Build-in break in the ScriptEngine? Best idea I can come up with
>> without enabling exceptions.
>
> Only problem: Exactly that thread is blocked.

It should be running some loop but it's inside the script-engine. If
it would truly bock, i.e. control never goes back to C++ code, all
hope is lost and the thread has to be stopped. But I'm not sure that
is required.