Thread: Nonblocking FIFO

Greetings,
Simple issue, but my own research has turned up nothing.

I'm attempting to create an intra-process communication system to create a communication & control program for a server daemon running in the background.

Now, I've got the FIFO working properly, it can read and write commands rather well, only problem is, the entire system is rigged using FILE and fcommands, and all of my options to set the FIFO to nonblocking seem to deal with file descriptor integers, where FILE is an _IO_STREAM (or something like that)...

So my question, is there is possible way to make this FIFO nonblocking in such a way that I don't need to completely rewrite the module that I've made thusfar?

Originally Posted by @nthony

maybe something like this: fileno

What he said. Use fileno() to get the fd associated with the FILE object, then use fcntl() to make it non-blocking.

I'm using the functions in this order (example with limited details to prevent confusion)

Code:

main ( )
{
  initalize_fifo( )
  for ( ;; )
  {
     handle_fifo( );
  }
}

initalize_fifo( )
{
  mkfifo( FIFO_FILE, 0666 );
  <fifo clearing code>
}

handle_fifo( )
{
FIFO_DATA * fifo;
fifo = read_fifo( );

<more processing stuff here>
}

read_fifo( )
{
  FILE * fp;
  fp = fopen( filename, "rw" );
  fcntl( fileno( fp ), F_SETF, FNDELAY );

  <file reading code here>
}

and still it blocks, I considered using fcntl on FIFO creation, but mkfifo() doesn't return the fd, just creates it in the filetree. I may be able to rewrite it to use a global variable for the fifo's FILE struct.... is that what I need to do? or am I missing something here? it seems that right when it opens it blocks, not processing anything after it, and I can't exactly set that flag before it opens.... right?

Originally Posted by Teegtahn

Code:

  fcntl( fileno( fp ), F_SETF, FNDELAY );

NDELAY is not what you want. You need to read the flags with F_GETFL, then OR in the O_NONBLOCK bit, then set the flags back with F_SETFL.

Code:

int flags;
int fd;

fd = fileno(fp);
flags = fcntl(fd, F_GETFL);
fcntl(fd, F_SETFL, flags | O_NONBLOCK);

I'd be less irritated if I didn't really need this, but it's still blocking, I've changed the code to the following (for the read_fifo)

Code:

FIFO_DATA *read_fifo( char filename[256] )
{
        int fd, flags;
        FILE *  fp;

        FIFO_DATA *    fifo;
        CREATE( fifo, FIFO_DATA, 1 );

        if ( ( fp = fopen( filename, "r" ) ) == NULL )
        {
                perror( filename );
                exit( 1 );
        }

        fd = fileno( fp );
        flags = fcntl( fd, F_GETFL );
        fcntl(fd, F_SETFL, flags | O_NONBLOCK);

<FIFO Reading Code Here>
}

I really think it's blocking on fopen(), since it won't throw any error messages I put in between that and my first getc( fp ) call.

The process runs fine until I tell the server to try to handle the fifo.. it locks, and waits for me to issue a command from the client I wrote...

Mabye I should just rewrite it using open() so I can just pass the damn flag right when I open it.

my read statements no longer read from the pipe correctly, client returns a Broken Pipe error, and the server returns a (null) string...

I'm investigating myself, but it's no longer blocking.

Thank you

Originally Posted by Teegtahn

my read statements no longer read from the pipe correctly, client returns a Broken Pipe error, and the server returns a (null) string...

The server isn't closing/reopening the pipe repeatedly, is it?

not in one read cycle...

read_fifo opens and closes it once during it's run, but after it's read, the fifo is closed, the data is preserved, processed and the system starts again... it's running inline with a few other read/write modules

Originally Posted by Teegtahn

not in one read cycle...

read_fifo opens and closes it once during it's run, but after it's read, the fifo is closed, the data is preserved, processed and the system starts again... it's running inline with a few other read/write modules

The only reason you'd be getting a broken pipe signal in the client would be the client trying to write to a pipe that the server side had already closed.