Excellent paper, well that makes it completely clear what the MIT guy
means by restarting a system call. It is interesting that in their
approach they restart a read() or write() call or whatever they call
it in their system, with the buffer advanced and the count reduced.
This is a bit like what would happen in x86 if it gets interrupted in
a REP MOVSB instruction, it returns into REP MOVSB with SI/DI advanced
and CX reduced. However it would not work exactly right in unix due to
the return value from read()/write() being wrong. Anyway, I like the
unix way, it is nice and simple. I have never found it to be a problem
when devices return a "short read" or "short write", although it is
an
interesting semantic that if you opened the file yourself and you're
doing lseek on it, it cannot be a TTY, and short reads/writes do not
occur. Having a hypothetical system with a very slow disk (or fast
CPU) in which disk accesses are blocking, would break many programs.
cheers, Nick
On Wed, Feb 15, 2017 at 1:03 AM, Lars Brinkhoff <lars(a)nocrew.org> wrote:
Nick Downing <downing.nick(a)gmail.com> writes:
By contrast the MIT guy probably was working with
a much smaller/more
economical system that didn't maintain a kernel stack per process.
No. PCLSRing is a feature of MIT' ITS operating system, and it does
have a separate stack for the kernel.
Here is a copy of Alan Bawdens paper about PCLSRing:
http://fare.tunes.org/tmp/emergent/pclsr.htm