Re: messaging questions...

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:
: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 
:get EASYNC?

    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
:name.
 
    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
    semantics.

    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 
:context."
:
: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).

    					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>

:Still trying to understand :).  One day I will try to run this at home 
:again.
:
:Dave
: