Centralized 'thread active' handling

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Gunnar Roth wrote:
> Klaus Schmidinger wrote:
> 
>> Stefan Huelswitt wrote:
>>
>>> On 13 Aug 2005 Klaus Schmidinger <Klaus.Schmidinger@xxxxxxxxxx> wrote:
>>>
>>> Hi,
>>>
>>>
>>>> Fixed a race condition in cTransfer (thanks to Klaus ??? for 
>>>> reporting this one).
>>>> In doing so, the 'active' variables used by the actual derived 
>>>> cThread classes
>>>> have been replaced by the cThread::Active() function. The previous 
>>>> functionality
>>>> of cThread::Active() has been moved into the new cThread::Running().
>>>> Plugin authors should check their derived cThread classes and 
>>>> replace any 'active'
>>>> variables the same way as, for instance, done in transfer.c.
>>>
>>>
>>>
>>>
>>> Wouldn't it be better to leave Active() untouched (instead of
>>> renaming to Running()) and create a new (differently named)
>>> function for the active var replacement? (e.g. Continue(), which
>>> would give good readability with while(Continue()))
>>
>>
>>
>> Well, Active() reflects the internal 'active' variable, so
>> Continue() would have to correspond to 'continue', which is
>> a reserved keyword...
>>
> What has the name of a method to do with te name of a internal variable?

Well, nothing, technically - it's just that I like to do it that way.
Now, before you start dissecting VDR and showing me places where I did
it differently, let's just end this here ;-)

>>> This would limit the impact this change has to plugins.
>>>
>>> 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()?
> 
> 
> /In the vbox plugin i use some code from mp3 plugin and there i have a 
> Active() call which simply returns active member of cTrhead.
> 
> IMO what stfean huelswitt says , is right.

Ok, I give up.
I'll leave the old Active() function as it was and call the new one
something like Continue() or so. I won't call it Terminate() or anyting
that requires an extra negation, though.

Now, with the naming problem settled, are there any actual, technical
issues with this modification?

Klaus


[Index of Archives]     [Linux Media]     [Asterisk]     [DCCP]     [Netdev]     [Xorg]     [Util Linux NG]     [Xfree86]     [Big List of Linux Books]     [Fedora Users]     [Fedora Women]     [ALSA Devel]     [Linux USB]

  Powered by Linux