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

[Jan Grant]

On Wed, 13 Aug 2003, Matthew Dillon wrote:

>     The interruptability of a normal system call basically translates to the
>     ability to abort a messaging system call.
>
>     Normally a messaging system call will not be aborted by a signal,
>     after all you might have hundreds of messaging system calls in progress
>     and you obviously don't want them all to abort every time you take a
>     signal.  But there will be cases where a program *will* want to abort
>     a system call after taking a signal.  For example, a program might want
>     to abort a sleep() that is in progress when it gets SIGINT.  The
>     difference between the traditional syscall mechanism and our new
>     messaging mechanism is that in the traditional mechanism the kernel
>     has no choice but to abort the system call in order to be able to
>     trampoline the signal in user land, and in the messaging mechanism
>     the kernel can wash its hands of the whole affair and leave it up to
>     the user program to decide whether to abort any of the in-progress
>     syscalls.

. ...except for sigkill, etc. right? In which case, the userland
shouldn't get a say in what it does; pending operations in the kernel
obviously need to complete/return or be stopped or otherwise mopped up
but the userland process itself is dying and shouldn't be required to
cooperate with the system to mop up any pending "waiting on return
messages", I'd have thought.


-- 
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/
Leverage that synergy! Ooh yeah, looking good! Now stretch - and relax.