On Thu, May 16, 2013 at 4:58 PM, Peter Soetens <peter [..] ...>wrote:

>
>
> Hi Adolfo,
>
> On Thu, May 16, 2013 at 3:28 PM, Adolfo Rodríguez Tsouroukdissian <
> adolfo [dot] rodriguez [..] ...> wrote:
>
>> Hi,
>>
>> I'm wondering how to properly manage the resources and lifecycle of a
>> RTT::os::TimeService instance. Considering that:
>>
>> - TimeService is a singleton, and resources are dynamically allocated the
>> first time TimeService::Instance() is called.
>>
>> - TimeService::Release() frees currently allocated resources, if any.
>>
>> How can I manage the lifecycle of this singleton when there is more than
>> one client in the same process, and they don't know about each other?. What
>> I'm potentially trying to avoid is something like:
>>
>> - Client A initializes the TimeService and starts using it in a realtime
>> context.
>> - Client B initializes the TimeService (no-op, as A already did this) and
>> starts using it in a realtime context.
>> - Client A is done and calls TimeService::Release()
>> - Client B tries to use the time service and ends up allocating resources
>> in a realtime context
>>
>> What other solutions are there apart from assuming a memory leak or a
>> potential mode switch?.
>>
>
> Since TimeService is only a few bytes of data, we instantiate it once and
> leave it alive during the whole process. Release is only called by the os
> stop functions of RTT. So don't call Release in client code.
>
>
Oh, OK!. So I also don't have to call TimeService::Instance() when setting
up the component to make sure that the first update() does not allocate
resources.

Thanks for the insight,

Adolfo.

Peter
>
>