UNIX for Advanced & Expert Users

Thanks Perderabo! Though the code is not mine to modify - and it is next to impossible to get the application team to change their code. So we gave them a different tmpdir and tightened up filesystem monitoring on our end.

You need to understand something about the fnnnnn calls. They make kernel requests
for read/write only at certain intervals. The only thing that forces a write is either fflush() or fclose(). And they don't do a thing except return an error value -1.

You can also call write() without checking the return code and have your code continue as though everything went okay. When in fact it did not. read() will screw up unless you do this on a busy system:

Code:

#include <unistd.h>
#include <fcntl.h>
#include <errno.h>
#include <stdlib.h>


ssize_t readall(int fd, void *buf, size_t nbyte)
{
     ssize_t nread = 0, n=0;

     do 
     {
         if ((n = read(fd, &((char *)buf)[nread], nbyte - nread)) == -1) 
        {
             if (errno == EINTR)
                 continue;
             else
                 return (-1);
         }
         if (n == 0)
             return nread;
         nread += n;
     } while (nread < nbyte);
     return nread;
}

It's a known deal: you must stress test a production app that uses a lot of I/O. Most apps fail in high I/O or low free disk space situations. Or fail when lots of preemption is present (process context switching)- i.e., super busy cpu.

I know all this because 25 years ago, all systems were overloaded by definition.
One user was too many.

PS: you can construct a similar writeall() function for the same reason: checking for EINTR.