More syscall messaging commits, and some testing code as well.
Jan.Grant at bristol.ac.uk
Tue Aug 12 07:04:08 PDT 2003
On Tue, 12 Aug 2003, Hiten Pandya wrote:
> On Mon, Aug 11, 2003 at 07:45:21PM -0700, Matthew Dillon wrote:
> > I just committed another bunch of syscall messaging stuff, plus I
> > also committed some test code for it in /usr/src/test. This is ad-hoc
> > test code and committers are welcome to throw in their own testing
> > code in that directory willy-nilly :-)
> Cool! ;-)
> > In this commit I have managed to asynchronize nanosleep(), but there
> > are still a bunch of issues that have to be worked through. For
> > example, we need resource limits on the number of outstanding system
> > calls we allow to be in-progress and there needs to be a mechanism to
> > abort system calls which are in-progress when a program is killed.
> Will the system calls be like atomic transactions? I.e., will it
> be possible to ^C a program, and the currently executing system
> call will rollback whatever it was doing?
> I guess what I am asking might be a little superficial...
With "traditional" system calls unless they're explicitly interruptable
(if they're long-lived) you need to wait until they return. I'd expect
a process to hang around marked as "dying" status after a sigkill
pending the return of extant noninterruptable syscalls. Having syscalls
interruptable at any point and "roll back" seems the wrong place to be
sticking a lot of complex code, and inviting trouble.
jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
Tel +44(0)117 9287088 Fax +44 (0)117 9287112 http://ioctl.org/jan/
Whenever I see a dog salivate I get an insatiable urge to ring a bell.
More information about the Kernel