There are various circumstances (for instance, the "delegation" discussed in
the previous issue), where it would be useful to look at all or some of a
message, without actually marking it as having been read.
Thus a "peak" mechanism is proposed, which allows the caller to retrieve some
or all of a message, but not remove it from the "next message to be read"
buffer.
The NEXTMSG ioctl prepares the next message for reading (putting it into the
"next message to read" internal buffer), and returns the number of bytes in
said message (and, of course, 0 if there is no next message).
The user then calls 'read' to read the bytes of the message. If they read all
of the bytes of the message, then the internal buffer is emptied (which is the
equivalent of "marking the message read").
So two approaches spring to mind:
1. Provide an ioctl to return the first N bytes of the message in the internal
buffer, or 0 bytes if there is none (or the actual number of bytes if that is
less than N). This makes peeking significantly different than reading, which
seems inelegant. It also makes it harder to investigate the message piece by
piece, if one is not sure what one is looking for.
2. Assume one will not read *all* of the message (because doing that marks the
message as read/clears it away), and have an ioctl to say "that wasn't a proper
(partial) read, reset the internal pointers to the start of the message again,
please". Given there is always a 'kbus' end guard at the end of the message,
this isn't *quite* as horrible as it sounds, but it is still fairly inelegant.
3. Provide a PEEKMSG ioctl which acts like NEXTMSG, but causes the subsequent
'read' not to clear the internal buffer if/when it finishes. After a PEEKMSG, a
NEXTMSG would revert to reading the *same* message. After a PEEKMSG, a DISCARD
would discard the message in the same way as it does after a NEXTMSG. After a
PEEKMSG, another PEEKMSG would drop the peaked-at message and get the next
messge (if any) into the internal next-message buffer.
At the time of writing, I think 3 is the least inelegant of the proposals, but
since this is not likely to be implemented soon, there is still time to think
about how this is best done.
Original issue reported on code.google.com by t...@tibsnjoan.co.uk on 8 Mar 2011 at 8:28
Original issue reported on code.google.com by
t...@tibsnjoan.co.ukon 8 Mar 2011 at 8:28