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

[Sander Vesik <sander@xxxxxxxxxxxxxxxxxxx>]

Jan Grant <Jan.Grant@xxxxxxxxxxxxx> wrote:
> 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).

Yes - fast, guaranteed to have bounded short lifetime syscalls need not be
interruptable. read() is not really bound timewise and hence should always
be interruptable. 

> 
> 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.
> 

Zombies don't (need to) keep any resources other than the process table slot
and resource usage metrics around. I wonder - how does this interact with
generating a core image? Would all the syscalsl be shown as returned?

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

-- 
	Sander

+++ Out of cheese error +++