The rmr_torcv_msg() function was improperly interpreting
the timeout setting with a value of 0 was given. The
expected behaviour is to return immediately if no messages
are waiting, but blocking was happening when used in
conjunction with the MT-CALL mode.
Signed-off-by: E. Scott Daniels <daniels@research.att.com>
Change-Id: Icbbd5705e1d631f3c78dc0c27a392f681dad8737
API and build change and fixe summaries. Doc correctsions
and/or changes are not mentioned here; see the commit messages.
+2019 September 25; version 1.8.2
+ Correct bug in rmr_torcv_msg() when timeout set to zero (0).
+
2019 September 19; version 1.8.1
Correct missing constant for wrappers.
set( major_version "1" ) # should be automatically populated from git tag later, but until CI process sets a tag we use this
set( minor_version "8" )
-set( patch_level "1" )
+set( patch_level "2" )
set( install_root "${CMAKE_INSTALL_PREFIX}" )
set( install_inc "include/rmr" )
chute = &ctx->chutes[0]; // chute 0 used only for its semaphore
- if( max_wait > 0 ) {
+ if( max_wait >= 0 ) {
clock_gettime( CLOCK_REALTIME, &ts );
if( max_wait > 999 ) {
- seconds = (max_wait - 999)/1000;
+ seconds = max_wait / 1000;
max_wait -= seconds * 1000;
ts.tv_sec += seconds;
}
d1[D1_CALLID_IDX] = (unsigned char) call_id; // set the caller ID for the response
mbuf->flags |= MFL_NOALLOC; // send message without allocating a new one (expect nil from mtosend
- if( max_wait > 0 ) {
+ if( max_wait >= 0 ) {
clock_gettime( CLOCK_REALTIME, &ts );
if( max_wait > 999 ) {
- seconds = (max_wait - 999)/1000;
+ seconds = max_wait / 1000;
max_wait -= seconds * 1000;
ts.tv_sec += seconds;
}