Sathya

[Log in to get rid of this advertisement]

I have the following problem with FIFO.

A process,

opens fifo in blocking mode for reading.
In a for loop
{
waits in select for 60 secs
if select returns > 0
Reads the data from fifo
On timer expiry continue with the for loop
}

When the select() looks for activity in the FIFO within 60 secs, suppose i remove the fifo manually, then the select does not recognise this situation and just returns 0. If this is the case, how can the code ever recognise that the FIFO is gone?

I removed the select logic, and just had the fread() within the loop. In this case also, after removing FIFO, fread() does not recognise that FIFO is gone and instead blocks permanently.

I tried the same scenario with a FILE instead of FIFO. A process opens a file in read mode, sleeps(20) secs, and then writes some string to file. When it sleeps for 20 sec, i manually deleted the file and after the process wakes up fread() fails with error "Bad File Descriptor".

Why is this not happening in case of FIFO. Why does select or fread not recoginise that FIFO is gone and set some errno appropriately.

Please clarify.

Thanks,
Sathya

Hko

** accidental double post. please ignore **

Hko

What happens is: when the fifo deleted while it still held open by one or more process(es), the fifo does remain to exist! You cannot open it again, since it has no name in the filesystem anymore, but it is still there (like a normal pipe) and used by the process(es) as if nothing happened.

Verify this by opening 3 terminals.

• In the first make a fifo: mkfifo /tmp/fifo. Then execute od /dev/urandom >/tmp/fifo (this writes random digits to the fifo contineously).
• In the second terminal run cat /tmp/fifo to read the digits from the fifo.
• In the third terminal delete /tmp/fifo. You will notice how both the reading and the writing process keep running.

If you now kill the writing process, the reading process will still have a valid fifo open: no error occurs.

In your case the process writing to the fifo probably opens and closes the fifo after each string written. The reading process still has a valid (though useless) fifo open and will wait for more.

The same should happen with normal files: when a process has a file open for writing when it is deleted, it will keep it open without an error and will still be able to the file (which nobody will ever see again). Why this did not happen when you tried is a mistery to me. Maybe when using the append flag or so has this effect, or you program has some bug. Hard to say without the code.