+The &ital(max_msg_size) parameter is used to allocate receive buffers and is the
+maximum message size which the application expects to receive.
+This value is the sum of &bold(both) the maximum payload size &bold(and) the maximum
+trace data size.
+This value is also used as the default message size when allocating message buffers.
+Messages arriving which are longer than the given maximum will be dropped without
+notification to the application.
+A warning is written to standard error for the first message which is too large on
+each connection.
+
+&space
+&ital(Flags) allows for selection of some RMr options at the time of initialisation.
+These are set by ORing &cw(RMRFL) constants from the RMr header file. Currently the
+following flags are supported:
+
+&half_space
+&beg_dlist(1i : &bold_font )
+&diitem(RMRFL_NONE)
+ No flags are set.
+
+&half_space
+&diitem(RMRFL_NOTHREAD)
+ The route table collector thread is not to be started. This should only be used
+ by the route table generator application if it is based on RMr.
+
+&half_space
+&diitem(RMRFL_MTCALL)
+ Enable multi-threaded call support.
+
+&half_space
+&ditem(RMRFL_NOLOCK)
+ Some underlying transport providers (e.g. SI95) enable locking to be turned off
+ if the user application is single threaded, or otherwise can guarantee that RMR
+ functions will not be invoked concurrently from different threads. Turning off
+ locking can help make message receipt more efficient.
+ If this flag is set when the underlying transport does not support disabling
+ locks, it will be ignored.
+&end_dlist
+
+&h3(Multi-threaded Calling)
+The support for an application to issue a &ital(blocking call) by the &cw(rmr_call()) function
+was limited such that only user applications which were operating in a single thread
+could safely use the function.
+Further, timeouts were message count based and not time unit based.
+Multi-threaded call support adds the ability for a user application with multiple threads
+to invoke a blocking call function with the guarantee that the correct response message
+is delivered to the thread.
+The additional support is implemented with the &ital(rmr_mt_call()) and &ital(rmr_mt_rcv())
+function calls.
+&space
+
+Multi-threaded call support requires the user application to specifically enable it
+when RMr is initialised.
+This is necessary because a second, dedicated, receiver thread must be started, and
+requires all messages to be examined and queued by this thread.
+The additional overhead is minimal, queuing information is all in the RMr message
+header, but as an additional process is necessary the user application must "opt in"
+to this approach.
Code Review / ric-plt / lib / rmr.git / blobdiff