[Xenomai] behavior of cobalt-wrapped fwrite()
brozgeo at gmail.com
Tue Dec 27 18:54:56 CET 2016
I'm running Xenomai 3.0.2, with Linux 3.18.20. I have an application
that uses the Cobalt (POSIX) API, using several Xenomai
threads/tasks (all priority > 0).
One of these threads makes several calls to fwrite(), each time
appending a chunk of data to a given open file on the flash file
system. The fwrite()'s are spread out; in between the calls, other
threads get a chance to run. Eventually, the file is fclose()'d.
The resulting file should be around 2MB, but ends up being about
200kB (and I'm not sure which 200kB that is). If I sum up the
returns of each fwrite() call made, then that returns the expected
2 MB size (which the resulting file does not reflect).
Compiled as a Linux application, this use of fwrite() works.
Running on Xenomai, if I use:
__real_fwrite() instead of fwrite()
then that also works (i.e. the full 2MB gets written).
I have tried to "fflush" after each fwrite(), and before the fclose(),
but that made no difference.
A similar situation is described for Xenomai 2.6.3 in this thread:
My question is... is this an issue with Cobalt's fwrite()
implementation, or am I expected to use __real_fwrite() in such
cases? And then, should I be using __real counterparts
for fopen, fread, etc. as well? And what is the litmus test
for using the __real_XXX prefixed function calls?
Thanks in advance for any advice!
Moog Industrial Group
More information about the Xenomai