bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: mach_msg blocking on call to vm_map


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 1, 2016 at 1:18 PM, Richard Braun <rbraun@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
 


reply via email to

[Prev in Thread] Current Thread [Next in Thread]