On Thu, Sep 1, 2016 at 1:18 PM, Richard Braun <rbr...@sceen.net> wrote:
> 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.
>
What happened with select? mach_msg() returned prematurely? I can handle
that fine. In this case, mach_msg() isn't returning at all.
> 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.
>
I've thought of that. It might be desirable at some point for performance,
but do I really need it for correctness? I just have to accept that
mach_msg can hang once in a while and make sure that I can burn its thread
if it does?
I don't like that idea at all! It's just ugly.
At least for RPCs. Is there a way you can detect whether a message
> implies a reply ?
Well, vm_map implies a reply. The troublesome mach_msg() call hangs
indefinitely, though, so there's no point in waiting for a reply. Just
start using another thread?
agape
brent
