# Issue with the timer

**URL:** <https://forum.legato.io/t/issue-with-the-timer/3282>\
**Category:** Legato Application Framework\
**Created:** [May 16, 2018, 12:14pm UTC](https://forum.legato.io/t/issue-with-the-timer/3282 "2018-05-16T12:14:40Z")\
**Posts on this page:** 6\
**Page:** 1

<div class="post-metadata">

**Author:** ![kamleshgurudasani](https://avatars.discourse-cdn.com/v4/letter/k/e0b2c6/32.png) [@kamleshgurudasani](https://forum.legato.io/u/kamleshgurudasani)\
**Post date:** [May 16, 2018, 12:14pm UTC](https://forum.legato.io/t/issue-with-the-timer/3282/1 "2018-05-16T12:14:41Z")

</div>

I have initialized a timer with its expiry handler in Component\_init. It was working properly. but then I added a while(1) loop after starting the timer in component\_init.  
Now, my timer is never going in the timer expiry handler. can you explain this behaviour?

---

<div class="post-metadata">

**Author:** ![jyijyi](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.legato.io/jyijyi/32/822_2.png) [@jyijyi](https://forum.legato.io/u/jyijyi)\
**Post date:** [May 17, 2018, 2:51am UTC](https://forum.legato.io/t/issue-with-the-timer/3282/2 "2018-05-17T02:51:15Z")

</div>

how about using timer with threads like below?

#include “legato.h”

static int set\_up = 0;  
static pthread\_mutex\_t mutex = PTHREAD\_MUTEX\_INITIALIZER;  
static pthread\_cond\_t condition = PTHREAD\_COND\_INITIALIZER;

static void \*thread(void \*aArgument)  
{  
pthread\_mutex\_init(&mutex, NULL);  
pthread\_cond\_init(&condition, NULL);  
set\_up = 1;

```
int total_cycles = 10;

while (total_cycles--)
{
pthread_mutex_lock(&mutex);
pthread_cond_wait(&condition, &mutex);
pthread_mutex_unlock(&mutex);

printf("execute %i\n", total_cycles);
}

set_up = 0;
pthread_mutex_destroy(&mutex);
pthread_cond_destroy(&condition);

return NULL;

```

}

void alarm\_handler(int sSignal)  
{ if (set\_up) pthread\_cond\_broadcast(&condition); }

COMPONENT\_INIT  
{  
LE\_INFO(“Hello, world.”);

pthread\_t timed\_thread = (pthread\_t) NULL;

```
pthread_create(&timed_thread, NULL, &thread, NULL);

signal(SIGALRM, &alarm_handler);

struct itimerval timer_setup = { .it_interval = { 1, 500 * 1000 },
                                    .it_value = { 2, 0 } };

setitimer(ITIMER_REAL, &timer_setup, NULL);

//pthread_join(timed_thread, NULL);

```

while (1)  
{  
LE\_INFO(“Hello, world.2”);  
sleep(2);

}

}

---

<div class="post-metadata">

**Author:** ![kamleshgurudasani](https://avatars.discourse-cdn.com/v4/letter/k/e0b2c6/32.png) [@kamleshgurudasani](https://forum.legato.io/u/kamleshgurudasani)\
**Post date:** [May 17, 2018, 6:58am UTC](https://forum.legato.io/t/issue-with-the-timer/3282/3 "2018-05-17T06:58:08Z")

</div>

Hi jyijyi,

Thanks for the work around solution.

After working on it, a little bit more. I understood that timer won’t go to the expiry handler till entire component\_init is executed.

case 1:  
So basically if timer is started in component\_init with 2 sec of expiry count and if we put sleep(10) just after that, expiry handler will be called after 10 secs.

COMPONENT\_INIT  
{  
LE\_INFO(" component started");

```
block_read_timer = InitializationMngSetAndStartTimer(2,NULL); 

LE_INFO("---------------------------------Starting the thread--------------------------------");
sleep(10); 

```

}

case 2:  
Also, I found the work around by creating a thread for the execution of sleep(10), expiry handler was called correctly after 2 secs.

COMPONENT\_INIT  
{

```
LE_INFO("InitializationMng component started");
le_thread_Ref_t init_thread;

init_thread = le_thread_Create("MngInit",MngInit,&block_read_timer);
block_read_timer = InitializationMngSetAndStartTimer(2,NULL); 

LE_INFO("---------------------------------Starting the thread--------------------------------");
/* sleep(10); is added in the thread now */
le_thread_Start(init_thread);

```

}

As per explained in the case 1, is this the expected behavior of component\_init? If yes, can you explain it a little bit?

regards,  
Kamlesh

---

<div class="post-metadata">

**Author:** ![jyijyi](https://sea1.discourse-cdn.com/flex019/user_avatar/forum.legato.io/jyijyi/32/822_2.png) [@jyijyi](https://forum.legato.io/u/jyijyi)\
**Post date:** [May 17, 2018, 8:32am UTC](https://forum.legato.io/t/issue-with-the-timer/3282/4 "2018-05-17T08:32:10Z")

</div>

I found this is not only related to COMPONENT\_INIT().  
I tried to run the following code , but timer is no longer called every 3 seconds, but it is called every 5 seconds.

* * *

#include “legato.h”

#define TIMER\_INTERVAL\_SEC 3  
#define TIMER\_INTERVAL\_uSEC 100000

le\_timer\_Ref\_t adxlPollingTimer;  
static void tmrHandler(le\_timer\_Ref\_t timerRef) {  
LE\_INFO(“INSIDE TIMER”);

sleep(5);

}

COMPONENT\_INIT  
{  
LE\_INFO("Hello, world. ");

```
le_clk_Time_t clk = { .sec = TIMER_INTERVAL_SEC, .usec = TIMER_INTERVAL_uSEC };
	 adxlPollingTimer = le_timer_Create("ADXL_TIMER");
	le_timer_SetRepeat(adxlPollingTimer, 500);
	le_timer_SetInterval(adxlPollingTimer, clk);
	le_timer_SetHandler(adxlPollingTimer, tmrHandler);
	le_timer_Start(adxlPollingTimer);

```

}

* * *

I guess it is related to the description in here:

> **[Timer API - Legato Docs](http://docs.legato.io/latest/c_timer.html)**
>
> legato™ is an open source Linux-based embedded platform designed to simplify connected IoT application development

“The call to the timer expiry handler may not occur immediately after the timer expires, depending on which other functions are called from the event loop. The amount of delay is entirely dependent on other work done in the event loop. For a repeating timer, if this delay is longer than the timer period, one or more timer expiries may be dropped. To reduce the likelihood of dropped expiries, the combined execution time of all handlers called from the event loop should ideally be less than the timer period.”

---

<div class="post-metadata">

**Author:** ![kamleshgurudasani](https://avatars.discourse-cdn.com/v4/letter/k/e0b2c6/32.png) [@kamleshgurudasani](https://forum.legato.io/u/kamleshgurudasani)\
**Post date:** [May 17, 2018, 10:30am UTC](https://forum.legato.io/t/issue-with-the-timer/3282/5 "2018-05-17T10:30:39Z")

</div>

Hi jyijyi,

I guess that’s the expected behavior of timer and can be explained in detail with this.

“The reason for that is that while a signal is being inside its handler, it is blocked. Blocked signals are set to pending, but not queued. The term “pending” means that the operating system remembers that there is a signal waiting to be delivered at the next opportunity, and “not queued” means that it does this by setting a flag somewhere, but not by keeping an exact record of how many signals have arrived.”

That explains dropping as well as the delaying part.

But with the case 1 (that i have stated in my previous reply), it is different. It is not in the timer expiry handler yet and still it is getting delayed. For which I haven’t found the satisfactory explanation yet.

As we already have the work around solution, it’s not a dire problem anymore. I wanted to know just because I’m curious.

Regards,  
Kamlesh

---

<div class="post-metadata">

**Author:** ![kamleshgurudasani](https://avatars.discourse-cdn.com/v4/letter/k/e0b2c6/32.png) [@kamleshgurudasani](https://forum.legato.io/u/kamleshgurudasani)\
**Post date:** [May 17, 2018, 12:10pm UTC](https://forum.legato.io/t/issue-with-the-timer/3282/6 "2018-05-17T12:10:03Z")

</div>

Well, I guess this part explains this behavior of component\_init from the link,

> **[Components - Legato Docs](http://docs.legato.io/latest/conceptsComponents.html)**
>
> legato™ is an open source Linux-based embedded platform designed to simplify connected IoT application development

“Every component implements a special initialization function (COMPONENT\_INIT in C). That function does whatever initialization is required for that component (e.g., initializes data structures, registers event handlers, starts threads, etc.) and returns. The process’s main thread (auto-generated by the Build Tools) **runs all the component initializers for all components in the executable and then enters the Legato event loop. The event loop then reacts to events by and calling registered handlers.** ”
