title: Handling 'intterupted system call' error when using timer
body: <p>I'm writing an application that uses timer to do some data acquisition and processing at a fix sample rate (200Hz).
  The application acts like a server and run in background. It should be controllable from other processes or other machines from UDP.</p>
  
  <p>To do so, I use the timer_create() API to generate SIGUSR1 periodically and call an handler that do the acquisition and the processing.</p>
  
  <p>The code to configure the timer is as follow (minus error check for clarity):</p>
  
  <pre><code>sa.sa_flags = SA_SIGINFO;
  sa.sa_sigaction = handler;
  sigemptyset(&amp;sa.sa_mask);
  sigaction(SIGUSR1, &amp;sa, NULL);
  sev.sigev_notify = SIGEV_SIGNAL;
  sev.sigev_signo = SIGUSR1;
  sev.sigev_value.sival_ptr = &amp;timerid;
  timer_create(CLOCK_REALTIME, &amp;sev, &amp;timerid);
  timer_settime(...)
  </code></pre>
  
  <p>The code above is called when a 'start' command is received from UDP. To check for command I have an infinite loop in my main program that call recvfrom() syscall.</p>
  
  <p><strong>The problem is, when a 'start' command is received, and then, the timer is properly started and running (using the code above), I get an 'interrupted system calls' error (EINTR) due the SIGUSR1 signal sent by the timer interrupting the recvfrom() call. If I check for this particular error code and ignore it, I finally get a 'connection refused' error when calling recvfrom().</strong></p>
  
  <p>So here my questions:</p>
  
  <ol>
  <li>How to solve this 'interrupted system calls' error as it seems to
  ignore it and re-do the recvfrom() doesn't work?</li>
  <li>Why do I get the 'connection refused' error after about twenty tries?</li>
  <li>I have the feeling that using SIGEV_THREAD could be a solution, as I understand it, create a new thread (like phread_create) without generate a signal. Am I right?</li>
  <li>Is the signal number important here? Is there any plus to use real time signal?</li>
  <li>Is there any other way to do what I intent to do: having a background loop checking for command from UDP and real-time periodic task?</li>
  </ol>
  
  <p>And here the bonus question:</p>
  
  <ul>
  <li>Is it safe to do the data acquisition and the processing in the handler or should I use a semaphore mechanism to wake up a thread that do it?</li>
  </ul>
  
  <p><strong>Solution:</strong>
  As suggest in an answer and in the comments, using SA_RESTART seems to fix the main issue.</p>
  
  <p><strong>Solution 2:</strong>
  Using SIGEV_THREAD over SIGEV_SIGNAL works too. I've read somewhere that using SIGEV_THREAD could require more ressources than SIGEV_SIGNAL. However I have not seen significant difference regarding the timing of the task.</p>