[PATCH 14/17] score: Thread life cycle re-implementation
Sebastian Huber
sebastian.huber at embedded-brains.de
Thu Mar 27 07:14:34 UTC 2014
On 2014-03-26 18:43, Gedare Bloom wrote:
>>>>> +RTEMS_INLINE_ROUTINE bool _Thread_Is_life_restarted(
>>>>> >>> >+ Thread_Life_state life_state
>>>>> >>> >+)
>>>>> >>> >+{
>>>>> >>> >+ return ( life_state & THREAD_LIFE_RESTARTED ) != 0;
>>>>> >>> >+}
>>>>> >>> >+
>>>>> >>> >+RTEMS_INLINE_ROUTINE bool _Thread_Is_life_terminated(
>>>>> >>> >+ Thread_Life_state life_state
>>>>> >>> >+)
>>>>> >>> >+{
>>>>> >>> >+ return ( life_state & THREAD_LIFE_TERMINATED ) != 0;
>>>>> >>> >+}
>>>>> >>> >+
>>>>> >>> >+RTEMS_INLINE_ROUTINE bool _Thread_Is_life_protected(
>>>>> >>> >+ Thread_Life_state life_state
>>>>> >>> >+)
>>>>> >>> >+{
>>>>> >>> >+ return ( life_state & THREAD_LIFE_PROTECTED ) != 0;
>>>>> >>> >+}
>>>>> >>> >+
>>>>> >>> >+RTEMS_INLINE_ROUTINE bool _Thread_Is_life_change_requested(
>>>>> >>> >+ Thread_Life_state life_state
>>>>> >>> >+)
>>>>> >>> >+{
>>>>> >>> >+ return ( life_state & THREAD_LIFE_RESTARTED_TERMINATED ) != 0;
>>>>> >>> >+}
>>>>> >>> >+
>>> >>
>>> >>And also doxygen for these functions, and consider using the present
>>> >>tense for restarting, terminating
>> >
>> >
>> >Why would you document functions like this?
>> >
> For the sake of completeness.
To do something for completeness is a bad argument.
> However, the only one that really needs
> it is the last one. It is not quite clear from the name what it
> entails.
>
I see really no sense in adding documentation for functions that test two bits
and are not part of the application API.
What about the name _Thread_Is_life_changing()?
--
Sebastian Huber, embedded brains GmbH
Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail : sebastian.huber at embedded-brains.de
PGP : Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
More information about the devel
mailing list