Re: mach_msg blocking on call to vm_map

[Richard Braun]

On Thu, Sep 01, 2016 at 09:58:00AM -1000, Brent W. Baccala wrote:
> The big problem, as I see it, is that mach_msg() is blocking, and that
> hangs my entire thread.  It seems to me that these low-level RPC operations
> like vm_map can't block, otherwise it would defeat the purpose of
> MACH_SEND_TIMEOUT.  So vm_map() should record the mapping and then return,
> putting the copy operation on some kind of queue.  I guess.
> 
> Any thought on how to resolve this?

I completely disagree. 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.

I don't see anything wrong with vm_map misbehaving if the underlying
implementation is wrong, just fix that implementation, e.g. by
actually taking the send timeout into account here, or making
libpager handle multiple clients like you want.

Queuing the operation would only add tremendous complexity to an
already extremely complex IPC mechanism where messages are
allowed to be partially sent... Besides, the Unix semantics
often require blocking, since the original system calls are,
well, completely synchronous with respect to user thread
execution (it's actually the very same thread running kernel
code). So you'd only add another layer of synchronization,
and it would block there.

My personal opinion on the matter is that you should only invoke
remote objects if you trust them. The original Hurd design,
however, was explicitly meant to allow clients and servers to
be "mutually untrusting". I'm not exactly sure what this means
in practice but it seems that clients can detach themselves from
servers at any time. So making the timeout work, and allowing the
transaction to be interrupted (usually with a - hardcoded ? check
how glibc handles Ctrl-C/SIGINT during an RPC - 3 seconds grace
delay before brutal interruption) may be the only things required
to make the behaviour comply with "Hurdish expectations".

-- 
Richard Braun