Re: mach_msg blocking on call to vm_map

[Richard Braun]

On Thu, Sep 01, 2016 at 01:02:18PM -1000, Brent W. Baccala wrote:
> 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.

Oh, OK. But then why pass msg->msgh_remote_port as rcv_name ?

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

I don't think you can have that. Remember what I wrote about select ?
It's a bit similar here. a timeout of 0 means mach_msg isn't going to
block and instead return immediately, but that only concerns message
passing, not the server operation itself. In this case, the server is
the kernel, and the vm_map call itself has no associated timeout.

In my opinion, your network server should do what all servers do,
i.e. dedicate a thread to the processing of a complete RPC and spawn
as many as necessary when receiving messages. 

-- 
Richard Braun