DragonFly kernel List (threaded) for 2003-07
Re: just curious
:Peter da Silva <peter@xxxxxxxxxxx> wrote:
:> you don't want to repeat the mistake of the Amiga where programs taking
:> advantage of things like this prevented better implementations later on.
:> What happens if the API changes so messages are copied... or *not* copied...
:> or it differs from implementation to implementation.
: In which way are the messages changed? Do you refer to ln_Type or some
: private data in an extended message?
I think a good example of how in-flight modifications can be bad is
our current buffer cache implementation (struct buf), where interemdiate
DEV layers mess around with random fields. If you look at
/usr/src/sys/sys/buf.h you will see the resullt.. the struct buf has
b_driver1, b_driver2, b_saveaddr, b_ this , b_ that... all because
multiple layers want to mess around with the struct buf structure during
the I/O. And over the years plenty of bugs have popped up due to that
I am sure there will be a few special cases here and there, but generally
chaining messages should be restricted to one of two forms:
(1) An intermediate agent is able to handle the message. It handles the
message and returns it, not chaining or queueing to any more agents.
(2) An intermediate agent needs to translate the message for further
action. It makes a copy of the message (possibly into a far more
involved structure, consider the additional needs in a protection
layer crossing!), translates the copy, and chains the copy on using
its own reply port so replies would go back to this agent which
would translate the reply and adjust and return the original message.
Now I know copying sounds bad, but for such small blocks of data as
typically comprise a message I really think the overhead is going to be
in the noise especially considered our very light weight messaging model.
Linear copies of small blocks of data on modern cpus are insanely fast.