[Bug 722] Orocos should annotate thread-safety/real-timeness in API docs

http://bugs.orocos.org/show_bug.cgi?id=722

Peter Soetens <peter [..] ...> changed:

What |Removed |Added
----------------------------------------------------------------------------
Severity|minor |enhancement

--- Comment #2 from Peter Soetens <peter [..] ...> 2011-03-14 11:25:56 CET ---
(In reply to comment #0)
> We should annotate most functions in RTT to indicate if they are real-time or
> not and thread-safe or not.
>
> Doxygen allows to define custom @ tags, which are expanded to what you define.
> We could introduce:
>
> tag : User visible description in API docs.
>
> @nrt : Never real-time.
> @art : Always real-time.
> @crt : Conditionally real-time (depends on (template) arguments of
> class/function)
>
> @nts : Not thread-safe (User needs to guard with locks).
> @ats : Always thread-safe
> @cts : Conditionally thread-safe (depends on (template) arguments of
> class/function)
> @lts : Limited thread-safe. Only a limited number of threads may access this
> class/function at the same time.
>
> Some of these will require additional documentation in the function or class
> description to describe the conditions or limitations.
>
> They can easily be added as we're going and it could even allow some form of
> checking (for example, an @art tagged function calling an @nrt function).

This is still an open issue we should address by adapting our coding style.

Peter

[Bug 722] Orocos should annotate thread-safety/real-timeness in

On Mar 14, 2011, at 06:25 , Peter Soetens wrote:

>
> http://bugs.orocos.org/show_bug.cgi?id=722
>
> Peter Soetens <peter [..] ...> changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> Severity|minor |enhancement
>
> --- Comment #2 from Peter Soetens <peter [..] ...> 2011-03-14 11:25:56 CET ---
> (In reply to comment #0)
>> We should annotate most functions in RTT to indicate if they are real-time or
>> not and thread-safe or not.
>>
>> Doxygen allows to define custom @ tags, which are expanded to what you define.
>> We could introduce:
>>
>> tag : User visible description in API docs.
>>
>> @nrt : Never real-time.
>> @art : Always real-time.
>> @crt : Conditionally real-time (depends on (template) arguments of
>> class/function)
>>
>> @nts : Not thread-safe (User needs to guard with locks).
>> @ats : Always thread-safe
>> @cts : Conditionally thread-safe (depends on (template) arguments of
>> class/function)
>> @lts : Limited thread-safe. Only a limited number of threads may access this
>> class/function at the same time.
>>
>> Some of these will require additional documentation in the function or class
>> description to describe the conditions or limitations.
>>
>> They can easily be added as we're going and it could even allow some form of
>> checking (for example, an @art tagged function calling an @nrt function).
>
> This is still an open issue we should address by adapting our coding style.

I like this idea, though I also understand just how long it will take us to completely resolve it. I regularly wonder what functions are real-time or not, and end up grok'ing code to determine the answer. :-(
S