Re: dos server deaths

From: Andrew Valencia <vandys_at_nospam.org>
Date: Wed May 04 1994 - 08:49:10 PDT

[Dave Hudson <dave@humbug.demon.co.uk> writes:]

> Boot process 8 dies
>Process 8 is my dos server :-(
>If I then use q I go back to the command prompt and the dos server is still
>there quite happily :-)

Aha! No, everything is quite peachy, I just need to fix my debug code. You
see, filesystem servers need to tell the kernel to uncache executable images
when they're trying to delete them (the kernel holds an open port to the
image while it's cached). So, the server wants to make a kernel request,
but the kernel, as a part of trying to uncache the executable, turns around
and sends a MSG_DISCONNECT back to the server. But the server is busy
making the uncache request call, so you deadlock.

The way I deal with this is to start a new thread, and have *him* make the
uncache request. Thus, the main server thread gets to continue, sees the
MSG_DISCONNECT and cleans up, and that other thread then dies.

I guess the trap to kernel debugger should only be for the case of the
*last* thread dying inside a boot server. I'll correct this for the next
release. For now, either let the kernel continue or go take the debug code
(I think it's in os/kern/proc.c) out.

If you look at the code for the C library unlink() call, it checks for
EAGAIN and does indeed sleep and retry. It does this so it can leave time
for the uncache to happen, if needed.

                                                Andy
Received on Wed May 4 09:03:54 1994

This archive was generated by hypermail 2.1.8 : Wed Sep 21 2005 - 21:04:28 PDT