Thanks for al the replies:
1. The behaviour occurrs under Bookworm, and I do say that I will test other environments: I will replace the Pi5 with a Pi 4 in order to do that. The subject was intended to convey information, not criticism: but I'll try to edit the subject to emphasize this.
2. I have used fgets on a pi before, but embedd in an APL program, not C++, under Buster, and do not see this behaviour. I will, as I said run the C++ on older systems to establish the scope of this behaviour
3. I am testing this by sending input jessages from a terminal using fprintf. So yes... that almost certainly does open and close the fifo each time it is used, which would not be the case in the production system. However I I have tried putting multiple messages (each terminated by \n) in a single call from printf, and fgets reads (and correctly actions) only the first message. If I then try to cat or tail the fifo from another terminal (before or after terminating the C++ program) the messages that fgets has not read are not there, so it does look as if fgets flushes the whole fifo, not just the bit it has read, but I'll re-run these tests to check and re-post.
4. I am using fgets rather than getline because getline discards the terminating \n which means the C++ program has no way to tell if it has in fact received a complete message.
5. I have tried checking for errors on the fgets call:
if (fgets(msgbuf, msglen, fd) == NULL){
printf("read error : %d\n", ferror(fd));
}
and no errors are reported
6. Just to be clear, yes... I am trying to write a C++ program that, in effect, tails the fifo, receiving \n terminated messages one at a time, which it then actions. The program works absolutely fine provided that mesaages are written to the fifo one at a time, even in bits using multiple writes, and are less than 80 characters long. These assumptions are reasonable, but I don't want to leave them embedded in a production system that should run, unsupported, in multiple environments, for many years.
Thanks...
Peter
1. The behaviour occurrs under Bookworm, and I do say that I will test other environments: I will replace the Pi5 with a Pi 4 in order to do that. The subject was intended to convey information, not criticism: but I'll try to edit the subject to emphasize this.
2. I have used fgets on a pi before, but embedd in an APL program, not C++, under Buster, and do not see this behaviour. I will, as I said run the C++ on older systems to establish the scope of this behaviour
3. I am testing this by sending input jessages from a terminal using fprintf. So yes... that almost certainly does open and close the fifo each time it is used, which would not be the case in the production system. However I I have tried putting multiple messages (each terminated by \n) in a single call from printf, and fgets reads (and correctly actions) only the first message. If I then try to cat or tail the fifo from another terminal (before or after terminating the C++ program) the messages that fgets has not read are not there, so it does look as if fgets flushes the whole fifo, not just the bit it has read, but I'll re-run these tests to check and re-post.
4. I am using fgets rather than getline because getline discards the terminating \n which means the C++ program has no way to tell if it has in fact received a complete message.
5. I have tried checking for errors on the fgets call:
if (fgets(msgbuf, msglen, fd) == NULL){
printf("read error : %d\n", ferror(fd));
}
and no errors are reported
6. Just to be clear, yes... I am trying to write a C++ program that, in effect, tails the fifo, receiving \n terminated messages one at a time, which it then actions. The program works absolutely fine provided that mesaages are written to the fifo one at a time, even in bits using multiple writes, and are less than 80 characters long. These assumptions are reasonable, but I don't want to leave them embedded in a production system that should run, unsupported, in multiple environments, for many years.
Thanks...
Peter
Statistics: Posted by Peter Cyriax — Sun Feb 11, 2024 8:39 am