[vdr] calling MainMenuAction() from an other plugin

[Reinhard Nissl]

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()))
>>     {
>>
>> 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.

Should be ok too. It's similar to call it earlier in the next loop run ;-)

Bye.
-- 
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rnissl at gmx.de