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

[Sander Vesik]

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

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. 

-- 
	Sander

+++ Out of cheese error +++