[vdr] Centralized 'thread active' handling

Stefan Huelswitt s.huelswitt at gmx.de
Sat Aug 13 17:43:52 CEST 2005

On 13 Aug 2005 Klaus Schmidinger <Klaus.Schmidinger at cadsoft.de> wrote:
> Stefan Huelswitt wrote:
>> On 13 Aug 2005 Klaus Schmidinger <Klaus.Schmidinger at cadsoft.de> wrote:
>>>Stefan Huelswitt wrote:
>>>>Otherwise a plugins using Active() now, could compile fine with
>>>>the next VDR version, but certainly wouldn't work correctly.
>>>Is there any plugin that actually uses cThread::Active()?
>> Both mp3 & mplayer plugin do.
> And are you sure that this is _really_ necessary?
> Do they _really_ want to determine whether the thread
> is still running, or would they just like to know whether
> it's time to return from the Action() function?
> I don't know the internals of these plugins, therefore
> my question.

I dunno if it's necessary, but for me it's common practice in a
player plugin. The derived cControl class calls player->Active()
so see if the derived cPlayer class (which in most cases is a
cThread as well) is still running. Like in:

eOSState cMP3Control::ProcessKey(eKeys Key)
  if(!player->Active()) return osEnd;

But there are other cases where the call is usefull.

And yes, if Active() is called, I want to know if the thread is
still running, as this is the only purpose of this function (up
to now).

You may argue, that I'm using (the old) Active() in an incorrect
way, but nevertheless I think that any API change should be made
in a way that existing plugins either continue to work properly
or fail to compile. Anything else will lead to massive confusion
for the average user.

>> To make it worse, they don't access the old "active" var, so I
>> guess your changes won't make them fail compile.
> That variable was private to some derived cThread classes in VDR,
> so they couldn't have accessed them, anyway. I was referring to
> cases where plugins might have used an 'active' variable (or whatever
> they may have called it) in the same way VDR did.

You're right. My plugins use an own variable but in a similiar
way as the internal one.


Stefan Huelswitt
s.huelswitt at gmx.de  | http://www.muempf.de/

More information about the vdr mailing list