>
> Now, some "Johnny come lately" coders, not to be confused
> with Software Engineers, think that you can bypass all that
> by doing physical writes to hardware. They are not only
> uninformed but dumb, i.e., stupid.
well, actually my name is bill. but you can call me, johnny.
i remember a time when it was announced by the behemouth of the day, IBM,
that in the future our files would be blocked by the operating system
and that we would no longer have the joy of creating those blocks
of data. oh , we rebelled, we bitched, we complained. but after we
stopped crying, we realized that not only was it something that
the operating system could do better, it was a really boring task.
the kernel(nucleus, operating system and any of thousand other names,
some (tm), some not) has the unenviable position of having to be all
things to all people. there is a guiding set of assumptions in the
wisdom behind the creation of an OS. those assumptions are
usually based upon a reasonable expectation of the hardware, some
arbitrary convention(unix) and visionary expectations of what
the user may need to do whatever job he(or she) may desire.
it is the width of the last of these that determines the limits of its
abilities and ultimately, its audience.
C is a high overhead convention. if the interface to the libs involves
further C, who knows how long it might take you to run a little
chunk of code which, once you get to it, may be slow, unwieldy
and marginally satisfactory.
if you don't like that, assemble it and link it right
into your program. all things to all people======> cool!
my complaint is not with guaranteeing database concurrency.
the state of the database is user business and if you don't
like the way the kernel is handling buffers, files or anything
else; no problem as long the esoterics exist to do it yourself.
people actually create event driven processes which, at some point,
require the participation of peripheral hardware. the process, itself,
must never stop. its children may be slow and dimwitted depending
upon whom their hardware friends are and upon whom they choose for
process companions but if the process stops, the user response becomes
unseamless.
i personally do not care whether the device is raw or not. i do
care when the dispatchability of my process is lost while the kernel
is waiting for notification that the io has completed. further,
what the device tells you about the last io sometimes predicates the
next(if one).
no matter how brilliantly the kernel is coded, it cannot predict
the nature of structures i have not yet imagined nor the inferences
that can be drawn from examining the io results against these
same structures.
i do not argure that circumstances do not exist in which we all,
as users, don't wait upon the kernel. we do and should.
io isn't one of them.
i'm private channeling this topic from now on to decrease
lecture potential.
johnny
p.s. richard j.
i predict SMP will have major problems in this area.
short of a coding bug, it seems conceivable that
an unviewable event is a plausible hypothesis
for why your smp box dies in idle.