Wait.. so in the kernel the rtf_put() call can fail if the fifo is too full? I thought it clobbered the existing data, but, not actually failed.. hmm. And you are also telling me that a read() system call in userland will NOT be interrupted for the duration of the system call? That is good news on one hand, but on the other I suspect such things affect real-time scheduler jitter :)
-Calin On Wed, 26 Sep 2001, Robert Kavaler wrote: > The problem you've outlined here will only happen if you read the fifo one > byte at a time. If you read it 8 bytes at a time then hard interrupts are > disabled for the entire duration of the read. To read 8 bytes at a time > issue the command "read(fifo_fd, buf, 8);" > > Also, on the writing side, writes will either write all their data > into a fifo or none of their data. So in your example, if the fifo > has 4 bytes left and you attempt to write "realtime", the write will fail. > > Given these two properties of fifos, the only real checking that you have > to do is to handle the discardded data when a write fails. There should > be no alignment or partial read/write problems. > > Robert Kavaler > > > > Date: Tue, 25 Sep 2001 13:26:38 -0400 (EDT) > > From: "Calin A. Culianu" <[EMAIL PROTECTED]> > > > > > > Let's say the RT Kernel thread is writing into an rtf as fast or slightly > > faster than the user process can consume the data. There are no > > guarantees that the user process won't hiccup on the data, are there? > > > > Let's say the rt kernel task keeps writing the string: > > > > "realtime" into a fifo of precisely 8 bytes, every, oh i dunno, 100ms. > > > > Now let's say my user process tries to read those 8 bytes. But after the > > 4th byte was interrupted. He just gets the word 'time', and 'real' > > is left in the fifo. Now, the rt-task runs before the user task and > > pushes in the word 'realtime' again, clobbering the word 'real' that > > was left. The user process tries to read in what he thinks are the > > remaining 4 bytes from the fifo, but he gets the word 'time' again. > > > > (Ok, so in reality the word would be written into the fifo backwards as: > > 'emitlaer' and read in forwards as 'realtime' but you get my point, > > right?). > > > > My question is this: What steps should a programmer take to at least be > > able to discard erroneous or hiccupped data coming from the rt-thread? > > More specifically, I plan on writing structs into the fifo and reading > > them in userland. I was thinking of delimiting these structs with a few > > bytes that would never appear in the structs themselves, that way the user > > process can synchronize its reads somewhat to those delimiters, as well as > > use magic numbers in the structs to identify the need to synchronize. > > > > Is this overkill? Is there a simpler approach to this dilemma? Should I > > not be worrying about this as the rtf driver is smarter than I give it > > credit for? > > > > Please help me overcome my fears, > > > > -Calin > > > > PS: I feel kind of uncomfortable writing structs in the fifo in the first > > place, but am too lazy to textualize the data and then re-parse it later. > > :/ > > > > > > > > > > -- [rtl] --- > > To unsubscribe: > > echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR > > echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED] > > -- > > For more information on Real-Time Linux see: > > http://www.rtlinux.org/ > > > > -- [rtl] --- > To unsubscribe: > echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR > echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED] > -- > For more information on Real-Time Linux see: > http://www.rtlinux.org/ > -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED] -- For more information on Real-Time Linux see: http://www.rtlinux.org/
