messaging questions...

David Leimbach leimy2k at mac.com
Wed Nov 19 12:40:05 PST 2003


    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.


Got that.

    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.

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 
on.

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() 
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 at xxxxxxxxxxxxx>
:Still trying to understand :).  One day I will try to run this at home
:again.
:
:Dave
:






More information about the Kernel mailing list