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/
