DragonFly BSD
DragonFly kernel List (threaded) for 2003-11
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: messaging questions...


From: David Leimbach <leimy2k@xxxxxxx>
Date: Wed, 19 Nov 2003 14:38:03 -0600

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
:





[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]