DragonFly kernel List (threaded) for 2003-11
Re: messaging questions...
:lwkt_domsg() sends a synchronous message waiting for some kind of
:reply. If we get EASYNC from the target we block. What if we don't
If you do not get EASYNC then the target handled the message
synchronously without blocking and completed the operation.
:lwkt_sendmsg() sends an asynchronous message but if the port returns
:anything that isn't EASYNC lwkt_sendmessage will queue its
:whole message on the reply port.
:What do you mean by "now complete"? If it sends asynchronously why
:would it send an incomplete asynchrounous message? Also I would think
:that EASYNC would imply that some error occurred while trying to do
:something asynchronous. I don't understand the rationale for the
All messaging functions return an 'error code'. EASYNC is not really
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 target
port function, which both lwkt_domsg() and lwkt_sendmsg() calls,
is *ALWAYS* supposed to return without blocking, regardless of whether
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 entire
operation will be considered completed. If the target port is not able
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 still
in progress and that the originator must either wait for the message to
be returned via the reply port, or that the originator must be sure to
retrieve the message from a reply port at some later 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() function
: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 originators
memory space, and the copy in the target address space. When the
target completes and replies to the message the target's copy must be
copied back to the originator's copy (at least those fields that contain
the response must be copied).
:Still trying to understand :). One day I will try to run this at home