Re: The problems for the rootless subhurd

[olafBuddenhagen]

Hi,

On Tue, Jun 09, 2009 at 02:25:53PM +0800, Da Zheng wrote:

> As I mentioned before, the subhurd sometimes hangs. I think I have
> found  one of the places where subhurd hangs.
[...]
> One place where subhurd hangs is when the exec server calls vm_map at
> some point. The proxy fails to forward the request of vm_map and
> mach_msg is blocked.
[...]
> I have enabled send timeout and the time to wait before giving up is 0
> (I tried some other values, and it didn't seem to work, either). I
> don't understand why mach_msg is still blocked even when the send
> timeout is enabled?

Well, I'm not sure what you are doing exactly, as I don't fully
understand your description. However, it seems that you are trying to do
the vm_map() call with a mach_msg() doing only send but no receive? I'm
not sure this is supported... Perhaps Mach assumes that you always want
to see the reply as well, and blocks the call until the processing is
done and it has a reply, whether you requested it or not...

Actually, if you want an ordinary RPC to timeout, you would have to set
the receive timeout as well -- it is perfectly possible that the send
succeeds immediately, but the receive waits for the reply. (In fact
that's probably the typical case.)

The only situation when a *send* can actually block, is when the
receiver doesn't process requests, and the message queue for the port
gets full.

However, as I already mentioned, it seems quite possible that the kernel
calls do not behave like ordinary RPCs.

As for why vm_map() specifically can block, I can see two possible
reasons: It may be that it waits for the pager to do something, and this
could block if the pager is broken. There is a remark in the
documentation of vm_map() that *seems* to indicate it doesn't wait for
the pager -- but it's not really clear, and I may be reading it wrong.

Another possibility is that the implementation of vm_map() itself can
hang in certain situations -- perhaps a bug.

In either case, I guess the only way to find out is looking at the
relevant code inside Mach.

-antrik-