|
From: | Brent W. Baccala |
Subject: | Re: mach_msg blocking on call to vm_map |
Date: | Thu, 1 Sep 2016 13:02:18 -1000 |
> > Most modern microkernels use synchronous IPC
> > that just block, and many operations on top of them do block. The
> > overall system on the other hand must be careful to avoid such
> > deadlocks.
>
> OK, I read the Mach documentation for mach_msg() and concluded that it was
> like a POSIX read(), that I could operate it in a mode where the kernel
> absolutely would not block my process, and would return EWOULDBLOCK
> instead. That's basically a kernel guarantee, at least as much as it is.
> (Notice that it doesn't guarantee how long the system call will take - 1
> ms? 1 s? 1 week? - because it's not a real time system, which is why I
> say "as much as it is")
Yes, you can think of mach_msg as such a system call. Note that if
the timeout is 0, it will return immediately instead of blocking,
which is what a real-time system would do too. Real time systems
aren't about that at all.
> Are you now saying that's not how it works on Mach/Hurd? If so, please let
> me know, because I've been under a big misunderstanding that I need to get
> cleared up!
I think your mistake here is using MACH_SEND_TIMEOUT instead of
MACH_RCV_TIMEOUT. Your message certainly was sent, so there is no
reason to get a timeout error for that.
Now that you know you should be using MACH_RCV_TIMEOUT, you should see
that no server can block you indefinitely.
[Prev in Thread] | Current Thread | [Next in Thread] |