DragonFly kernel List (threaded) for 2003-08
Re: More syscall messaging commits, and some testing code as well.
Jan Grant <Jan.Grant@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.
+++ Out of cheese error +++