C/C++ • Re: C++ fgets behaving very oddly on Bookworm (no other environment tested yet)

Hi AndyD,


Again... thanks.

This is all embedded in a yacht racing system which uses websockets, where the server is naturally the writer and the client the reader, not the other way round... Can we stick to "reader" and "writer" please I did not find what you posted confusing at all... the file read and write calls define which program is doing what.

I'm currently feeding data into the FIFO from a terminal session using printf. I'm sure this must open and close the fifo for each write. In the production system the writer would typically keep the FIFO open until the entire system is switched off ; but I could change it to open and close the FIFO each time it has a message to send if that helps any.

You say:

So each time the FIFO is opened for writing by the "client", the "server" will open the FIFO for reading. The "server" will keep reading from the FIFO until the "client" closes its writing handle. The fgets will then fail, by returning NULL and you should close the FILE handle and try again.

This is very helpful but a shade perplexing.

May I please first rewrite this as:

So each time the writer opens the FIFO, the reader will open it for reading, and will keep reading from the FIFO until the writer closes it for writing. The fgets will then fail, returning NULL; and you should close the FILE handle and try again

.

My reading of the documentation is that NULL is returned on the call to fgets if the FIFO is empty, whether or not the writer has closed the FIFO, and this is not classed as an error. Maybe that's just semantics, because what matters is that fgets returns a NULL. Which leads us to this:

So each time the writer opens the FIFO, the reader will open it for reading, and will keep reading from the FIFO until fgets returns a NULL. At this point the reader should close the FIFO and try again.

Again, appologies if I have misquoted you: I'm simply trying to understand.

But... the reader has no way to know when the writer is going to open the FIFO, or (if the writer keeps it open all the time) write to it. The reader can only try again immediately, and wait. So, the reader calls fgets, and two different things can then happen:
Scenario 1. fgets executes immediately, returning a NULL to indicate EOF (or FIFO empty): exactly what we DON'T want - it leads to a tight loop maxing out a CPU core.
Scenario 2. fgets waits in suspended animation until the OS tells it that there is data in the FIFO., whereupon it proceeds.

In the 2nd, desireable scenario, what the reader has done is to close the FIFO on receipt of the NULL, immediately re-open it and issue a new fgets call, which obligingly wats until there is data in the FIFO.

I will code it based on that, and see what happens.

But this does beg the question of why it is necessary for the reader to close the FIFO and immediately re-open it. However, my tests suggest that if the reader does not do the "close+open" bit, fgets will then move to Scenario 1.

Seems perverse to me, but if that's what fgets is meant to do, and the "close+open" solves my problem... well... THANKS


Peter

Statistics: Posted by Peter Cyriax — Sun Feb 11, 2024 6:20 pm

---