|
From: | Brent W. Baccala |
Subject: | Re: mach_msg blocking on call to vm_map |
Date: | Thu, 1 Sep 2016 13:34:43 -1000 |
On Thu, Sep 01, 2016 at 01:02:18PM -1000, Brent W. Baccala wrote:
> 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.
At least for RPCs. Is there a way you can detect whether a message
implies a reply ?
[Prev in Thread] | Current Thread | [Next in Thread] |