doc/011-idc/IDC.tex

69   start with \texttt{//} and continue until the end of the line.
75   must start with a letter or ``\texttt{\_}''.
84   literals have no specifier and hexadecimal literals start with
159     single unidirectional message with typed arguments,
163     messages (a call and the response) with a single declaration,
206 integer literal, defines an array type with the given \emph{arrayname}. This
245 The meta-parameters beginning with the context identifier are optional and may
262 For example, the following defines a message named ``dummy'' with three
279 syntax as for a simple message, but are prefixed with either \texttt{in} or
354 drivers, with implementations varying widely according to the properties of
362 Most interaction with bindings involves interface-type-specific functions.
364 named \texttt{iface} is used, with the following specification:
492     /* error handler for any async errors associated with this binding */
502 state with each binding object. It is not used by the binding implementation.
523 pointers. This table has an entry for each message type, with arguments
694 facilitate the rendezvous of \emph{threads} with \emph{events}, where an event
707 with the waitset; the concrete channel interfaces are specific to each
741               registered, and it is not associated with a waitset
742  \item[Idle:] an event handler closure has been registered with the
756  \item[Register:] Associates an event handler with a previously-unregistered
851 fixed-size (or variable-size with an upper bound) untyped data.
856 kernel-mediated communication with other dispatchers on the same core,
857 and is used to communicate with the local Monitor.
871 with a binding to its local monitor, as described in Section~\ref{sec:monitor}.
878 an iref, and returns it to the user along with the service identifier in an
884 monitor, and requests to bind with a specific interconnect driver. Although
897       with the iref, the client's (opaque) connection ID, and various parameters
912       then replies to its local monitor with a
931 code, can directly deliver a capability along with untyped message payload.
946      that capabilities can be associated with the correct messages.
963     representation, and forwards it on to the destination dispatcher with a
1001 When a message is sent, the sender invokes the remote endpoint cap with the
1005 then finds the endpoint with a message in it and invokes the trigger on the
1030 \subsection{Messaging with the local Monitor}
1034 \section{UMP: user-level message passing with coherent shared memory}
1050 buffer (Figure~\ref{fig:ump}), with each entry in the buffers being the size of
1071 many messages are outstanding and together with knowledge of the buffer size,
1075 channel buffers, then sending a cap to the buffer along with a bind request
1084 to serialise and deserialise a capability. The sender sends the capability with
1118 \chapter{Interaction with Hake build system}