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

[Jan Grant <Jan.Grant@xxxxxxxxxxxxx>]

On 12 Aug 2003, Sander Vesik wrote:

> Jan Grant <Jan.Grant@xxxxxxxxxxxxx> wrote:

[prelim cut]

> > 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.
> >
>
> The reverse of this is having a totaly useless machine as a lot of programs
> are stuck waiting stuff from a downed but non-soft mounted nfs volume.
> Philosophicaly, any user process should be killable at any time.

That doesn't mean every system call needs to be made interruptable. It
just means that long-lived system calls need to be interruptable: like
NFS mounts are if you turn on intr (not sure why anyone doesn't turn
that on).

Presumably you don't have a philosophical objection to a zombie process.
That's just hanging around waiting to be reaped. Effectively I'm just*
talking about extending the "zombie" status to wait until the count of
outstanding system calls goes to 0.

jan

* for potentially non-trivial values of "just", since you have to be
able to count syscalls pending for a particular process.

-- 
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/
Bolstered by my success with vi, I proceeded to learn C with 'learn c'.