Re: mach_msg blocking on call to vm_map

[Brent W. Baccala]

On Thu, Sep 1, 2016 at 12:38 PM, Richard Braun <rbraun@sceen.net> wrote:

> > 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.

Here's the call:

     mach_msg(msg, MACH_SEND_MSG | MACH_SEND_TIMEOUT, msg->msgh_size,
              0, msg->msgh_remote_port,
              0, MACH_PORT_NULL);

Why should I specify MACH_RCV_TIMEOUT?  It's not a receive call.

The way my code is structured, one thread handles the traffic from the network to IPC, and a separate thread handles the traffic from IPC to the network.  This call is in the network-to-IPC thread.  This thread never receives anything except network traffic, which it blocks for.

I want a non-blocking send.  This one blocks if the message is vm_map, the memory object passed in is goofed, and the message is targeted at a task port on the local kernel (and it doesn't have to be the task that calls mach_msg).

 

Now that you know you should be using MACH_RCV_TIMEOUT, you should see
that no server can block you indefinitely.

Just so we're on the same page here, should that call above block or not?

I just tried it again with MACH_RCV_TIMEOUT; it does the same thing.

    agape

    brent