[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