[vdr] Re: can the osd be accessed by a separate pthread?

[Clemens Kirchgatterer <clemens@thf.ath.cx>]

Klaus Schmidinger <Klaus.Schmidinger@cadsoft.de> wrote:

> Clemens Kirchgatterer wrote:

> > as i have already said: that is not the plugins fault. have you
> > tried this with any other plugin that opens an raw osd? i.e. with
> > klaus' own osddemo plugin?
> 
> Sorry, but it _is_ the plugin's fault!
> 
> A plugin that wants to open a raw OSD shall return a derived
> cOsdObject from its MainMenuAction() function. VDR will then call that
> object's Show() function and in _there_ the derived cOsdObject may
> call cOsd::OpenRaw()(and nowhere else!).

are you absolutly shure, that there is a difference between opening
the RawOsd in cOsdObject->Show() as you say and doing it in a thread
spawned from cOsdObject->Show() ? i can't see why this should matter.

> The derived cOsdObject must delete its raw OSD inside its desctructor
> (see the osddemo example).

the games plugin will shutdown when the destructor of the cOsdObject
derived object gets destructed. so from my point of view this is correct
behalfier also.

> While the derived cOsdObject exists, it may access the OSD even from
> a thread, because VDR will not access it while such an object exists.

yes, thats how i understood it also.

> However, VDR absolutely relies on the object to close the raw OSD in
> its destructor. After the destructor has run, VDR assumes full control
> over the OSD again. If the object doesn't play along, trouble is
> probably inevitable.

maybe the games plugin just takes a little bit to long before releasing
the osd. looks like an race condition. games plugin is about to release
the osd, but vdr already (re)opens it.

best regards ...
clemens


-- 
Info:
To unsubscribe send a mail to ecartis@linuxtv.org with "unsubscribe vdr" as subject.