Rik - messages are just streams of bytes to.
The big difference, which you almost get to, is that messages are
intended to be *potentially* deliverable asynchronously, whereas a
stream of bytes has no delivery semantics at all. In addition, a
message is intended to have some self-contained semantics, whereas a
stream of bytes has no semantics without a context in which to
interpret them.
In this sense, a stream of bytes is more fundamental than a
message. This observation points out that what we really need to unify
the now-kludgey collection of Unix I/O mechanisms is a common method
of doing async I/O delivery of a stream of bytes. Call it a message,
call it async file I/O, it doesn't matter.
Sometimes, it would be nice to say to the kernel:
"send me 50 bytes from this file every 10ms"
"whenever you've got 10K of this data stream ready to read,
send it to me"
which can be supported same general model that supports:
"tell me when 10ms has gone by"
"tell me when my heap size exceeds 100MB"
"tell me when another process has something to tell me"
"tell me when i tried to write to an illegal address"
As others have noted, it implies a very different programing model
that open/read/write/close, but its hardly an unfamiliar one in this
era of event-driven main loops.
--p
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/