A handler is a function used to receive messages from the network. The
user's code does not directly call handler functions. Rather, as a
message is extracted from the network, FM_extract() passes
control to the handler that FM_begin_message() had previously
associated with that message. Handlers take two arguments: an
FM_stream *, which represents the incoming message stream, and an
unsigned int, which is the sender's node number. Handlers return
either FM_CONTINUE to allow FM_extract() to continue
extracting or FM_QUIT to stop FM_extract()
prematurely.(6)
Handlers in FM 2.0 are different from handlers used in previous versions of FM and, in fact, from those used in all other handler-based messaging layers. The key distinction is that FM 2.0 handlers begin executing as soon as the first---as opposed to the last---piece of the message arrives. Furthermore, the target location of each piece of data can be specified dynamically, even after reading a previous piece of data from the same message stream. This makes message reception far more flexible than what is possible with a more traditional scatter vector.
To achieve this additional flexibility (and the resulting potential for
increased communication performance), the FM implementation must resort
to some underhanded trickery. As a result, the user must run a
source-to-source translator, streamify, on his handler code.
Because streamify and its companion program, streamer, are
currently implemented as a kludgy shell script and a rather
unsophisticated `lex' program, respectively,(7) the programmer is required
to provide some assistance by using
a set of #pragma directives.
Go to the first, previous, next, last section, table of contents.