Re: More syscall messaging commits, and some testing code as well.

[Jan Grant <Jan.Grant@xxxxxxxxxxxxx>]

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.