DragonFly kernel List (threaded) for 2003-11
Re: messaging questions...
All messaging functions return an 'error code'. EASYNC is not
an error, it just makes use of the error code space to tell the
originator that the message is being handled with asynchronous
The way to visualize the messaging system is that the low level
port function, which both lwkt_domsg() and lwkt_sendmsg() calls,
is *ALWAYS* supposed to return without blocking, regardless of
the originator requested synchronous or asynchronous operation. If
the target port is able to execute the request and return without
blocking then it will return something other then EASYNC and the
operation will be considered completed. If the target port is not
to execute the request without blocking it is supposed to queue the
message as appropriate and immediately return EASYNC. When the
originator sees an EASYNC result it knows that the operation is
in progress and that the originator must either wait for the
be returned via the reply port, or that the originator must be
retrieve the message from a reply port at some later time.
So, in essence, we are differentiating between a blocking call [there
is no blocking call per-se] and
whether the receiver can process the request in a blocking manner. If
it requires blocking processing
then we complete the request asynchronously and tell the caller to move
Essentially everything is "non-blocking" from the users perspective due
to the ability to queue work
up internally on a thread's work queue. That thread is not interacting
with users directly though I would
assume except maybe to deal with the reply port?
How am I doing? :)
This is a bit different from message passing as I am used to... but
then I work with MPI all the time.
:I think I understand the part about mp_SendMsg() working with the
:message as it came in synchronously without telling
:the message originator to "go away... I'll get it later".
:"User<->Kernel messaging interfaces simply employ mp_SendMsg()
:vectors which do the appropriate translation, so as far as the sender
:and recipient are concerned the message will be local to their VM
:I presume these vectors are how the system call interface is
:implemented via messages?
Yes. Basically if a message is transitioning an address space you
will wind up with at least two copies of it... the copy in the
memory space, and the copy in the target address space. When the
target completes and replies to the message the target's copy must
copied back to the originator's copy (at least those fields that
the response must be copied).
:Still trying to understand :). One day I will try to run this at home