[vdr] calling MainMenuAction() from an other plugin

[Klaus Schmidinger]

Reinhard Nissl wrote:
> Hi,
> 
> Klaus Schmidinger wrote:
> 
>>> In my case, I don't show an OSD. I just use this functionality as a 
>>> trampoline to have the VDR main thread execute my code for switching 
>>> the primary device, as it doesn't work reliably when it is done in 
>>> any other thread.
>>>
>>> So you are right, when a plugin opens an OSD (which is the typical 
>>> case), one will only see the OSD of the last plugin. On the other 
>>> hand, it would be useful to know for the caller, that the 
>>> MenuMenuAction of the specified plugin will be called when 
>>> CallPlugin() returned true. Otherwise it would need more 
>>> "intelligent" code at the caller to achieve the call under race 
>>> conditions.
>>>
>>> In the case where the above is of no interest, there is no need to 
>>> have an additional mutex lock in CallPlugin(), as Put() has one in 
>>> remote.c:79.
>>
>>
>> I'm not particularly fond of that FIFO of yours.
>> However, I do realize that it is useful to tell the caller of
>> cRemote::CallPlugin() whether the call was successful.
>> The attached patch vdr-1.3.46-callplugin.diff makes cRemote::CallPlugin()
>> return false if there is currently a plugin call pending.
> 
> 
> The code looks good to me. Am I right that CallPlugin() shall now only 
> be used to open the plugins main menu, i. e. no longer any other 
> processing in the context of the main thread?
> 
>> The ability to "catch the main thread" will be implemented by the
>> second attached patch (vdr-1.3.46-mainthreadhook.diff), so that no
>> "dirty tricks" should be necessary. This patch may have its line
>> numbers a little off, because I have already made other changes
>> to these files, but I wanted to give you a chance to look at this
>> and maybe comment on it before I release version 1.3.47 later today.
> 
> 
> I assume that this new interface function should be used for the code 
> which has nothing to do with the plugins main menu but was put in that 
> MainMenuAction() to execute the code in the context of the main thread.

Right. That was a dirty trick and I didn't want to manifest that ;-)

> In my case, the following code is to be executed in the new function:
> 
>   void cXineDevice::mainMenuTrampoline()
>   {
> #if VDRVERSNUM >= 10332
>     cMutexLock switchPrimaryDeviceLock(&m_switchPrimaryDeviceMutex);
>     if (m_switchPrimaryDeviceDeviceNo < 0)
>       return;
> 
>     cControl::Shutdown();
> 
>     if (m_switchPrimaryDeviceDeviceNo == (1 + DeviceNumber()))
>     {
>       char *msg = 0;
>       ::asprintf(&msg, tr("Switching primary DVB to %s..."), 
> m_plugin->Name());
> 
>       Skins.Message(mtInfo, msg);
>       ::free(msg);
>     }
> 
>     SetPrimaryDevice(m_switchPrimaryDeviceDeviceNo);
> 
>     if (m_switchPrimaryDeviceDeviceNo != (1 + DeviceNumber()))
>     {
>       char *msg = 0;
>       ::asprintf(&msg, tr("Switched primary DVB back from %s"), 
> m_plugin->Name());
> 
>       Skins.Message(mtInfo, msg);
>       ::free(msg);
>     }
> 
>     m_switchPrimaryDeviceCond.Broadcast();
> #endif
>   }
> 
> I see here a new problem, as I need to call cControl::Shutdown(), but 
> when VDR's main thread returns to it's main loop, it still may use 
> "Menu" which is most likely invalid at that time:
> 
>         // Main thread hooks of plugins:
>         PluginManager.MainThreadHook();
>         // User Input:
>         cOsdObject *Interact = Menu ? Menu : cControl::Control();
> 
> Maybe PluginManager.MainThreadHook() should be called earlier.

Originally I was thinking about actually putting it further down.
How about we put it to the very end of the "while (!Interrupted) {"
loop? That way it shouldn't interfere with anything.

I'll make it that way for version 1.3.47, which I will be releasing
shortly.

Klaus