Re: messaging questions...

[David Leimbach <leimy2k@xxxxxxx>]

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