[Xenomai] multiple failing writes to XDDP socket seem to block other I/Os

[Xenomai] multiple failing writes to XDDP socket seem to block other I/Os

[Thierry Bultel]

Hi,

With xenomai-2.6.4 on IMX6, I am facing an issue, that for now, and 
unfortunately, I have not been able to
narrow down to a simple test case, but I am still working on it.

Considering the following piece of code, where :

- globalLogFd is a XDDP socket, whose rtp backend is no longer 
listening. This works great when the rtp listener pops the messages.
- fp points to a classical text file

--------------

static int cpt;
void foo() { cpt++; };

static int cpt2;
void foo2() { cpt2++; };

--------------

     cpt=0;
     cpt2=0;

     for (uint32_t i = 0; i < index; i++ )
     {
         fprintf(stdout,"in loop: %d\n", i);
         char msg[256];
         sprintf(msg, "%d \n",i);

         size_t ret = write(globalLogFd,msg,strlen(msg)+1);
         if (ret != strlen(msg)+1) {
             foo();
         }

         count++;

         fprintf(fp,"%s",m_buffer[i]);
         foo2();

     }

     fflush(fp);
     fclose(fp);

The seen effect is that when the XDDP buffer is full, the I/O do not 
work anymore after some number of iterations. The cpt and cpt2 counters 
have been correctly incremented 'index' times, but neither the fprintf 
to stdout, nor the fprintf to fp do anything.
The context is not an RT thread. I am aware that sharing the globalLogFd
between RT and non RT threads is likely not a good idea.

The interesting thing to notice is that subsequent calls to the loop
make the thing happen again -> the fprintf work for a number of times
and then stop (about 300 times on a total of 1000).

Commenting out the write to globalLogFd lets the fprintf work for all 
iterations, as expected.

Best regards
Thierry

Re: [Xenomai] multiple failing writes to XDDP socket seem to block other I/Os

[Philippe Gerum]

On 11/17/2015 11:34 AM, Thierry Bultel wrote:
> Hi,
> 
> With xenomai-2.6.4 on IMX6, I am facing an issue, that for now, and
> unfortunately, I have not been able to
> narrow down to a simple test case, but I am still working on it.
> 
> Considering the following piece of code, where :
> 
> - globalLogFd is a XDDP socket, whose rtp backend is no longer
> listening. This works great when the rtp listener pops the messages.
> - fp points to a classical text file
> 
> --------------
> 
> static int cpt;
> void foo() { cpt++; };
> 
> static int cpt2;
> void foo2() { cpt2++; };
> 
> --------------
> 
>     cpt=0;
>     cpt2=0;
> 
>     for (uint32_t i = 0; i < index; i++ )
>     {
>         fprintf(stdout,"in loop: %d\n", i);
>         char msg[256];
>         sprintf(msg, "%d \n",i);
> 
>         size_t ret = write(globalLogFd,msg,strlen(msg)+1);
>         if (ret != strlen(msg)+1) {
>             foo();
>         }
> 
>         count++;
> 
>         fprintf(fp,"%s",m_buffer[i]);
>         foo2();
> 
>     }
> 
>     fflush(fp);
>     fclose(fp);
> 
> The seen effect is that when the XDDP buffer is full, the I/O do not
> work anymore after some number of iterations. The cpt and cpt2 counters

fprintf() relays output data to a low priority thread using lockless
buffers not to delay the real-time caller.

Since the caller has higher priority than the thread handling the stdio
stream, and your code spins indefinitely in that loop without ever
blocking, receiving -ENOMEM continuously:

- how is the relay thread supposed to be able to run for handling the
output?

- how is the non-rt XDDP receiver supposed to consume the data, so that
the -ENOMEM condition would stop on the send side?

Any code that keeps sending requests without acting upon a failure code
it receives doing so, is just asking for trouble.

-- 
Philippe.