While the following information is not crucial to using FM 2.0, some users may be interested in knowing some of the implementation-specific subtleties. Because the FM implementation will definitely change in future releases, programmers are strongly discouraged from writing programs that rely on this information.
The same handler may be called multiple times per message stream,
even though it gives the illusion of running only once. When a handler
tries to FM_receive() data that hasn't yet arrived, it saves its
state and returns control to FM_extract(). When
FM_extract() extracts data that a handler was waiting for, the
handler is re-entered where it left off, and the newly-arrived data is
processed. Note that the only place a handler can yield control is in
FM_receive().
The reason FM_extract() is allowed to extract slightly more than
the specified number of bytes is because the FM 2.0 implementation
segments messages into small packets, each of which must be read in its
entirety. If FM_extract() were forbidden from extracting extra
data, programs trying to extract less than a packet's worth of data
would hang.
There are only two situations in which FM_begin_message() can
fail (i.e. return NULL). The first is if another thread is
already in the process of sending a message, and therefore has the send
queue locked. The second is if FM_begin_message() is called from
within a handler and tries to begin a message for which insufficient
resources are immediately available. (This is used for deadlock
avoidance.) Note that if a handler tries to send a particularly large
message, there may never be sufficient resources to send it, and
any attempt will return NULL.
Go to the first, previous, next, last section, table of contents.