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/
