Anyone can explain UART callback in TivaC 1294 mode to me?

Is there an example usage of callback function? From RTOS user manual, it gives:

UART_MODE_CALLBACK is non-blocking and will return while data is being sent in the context of
a Hwi. The UART driver will call the callback function whenever a write or read finishes. In some
cases, the action might have been canceled or received a newline, so the number of bytes
sent/received are passed in. Your implementation of the callback function can use this information
as needed.

On this forum, I find the following snippet. The line on function below is really weird to me. 

  UART_readCancel(sRadio_UART_handle);

Anyone can tell me whether it must use this function call, following the previous read function?

Thanks,

ERROR_CODE eRadio_chk_settings (void)
{
#define SETTINGS_BUFF_SZ  1024
#define SET_SETTING_BUFF_SZ 64

  ERROR_CODE eEC = ER_OK;
  int iCmp_rslt = 0;
  uint16_t uiRcvd_len;
  int iStr_Len = 0;
  char cEcho_Check = 0;
  char * cBT_Rcvd_Settings = NULL;
  eEC = eUsing_radio_uart_dma();
  char * cSetting = NULL;
  char cBT_setting[SET_SETTING_BUFF_SZ ];
  int i = 0;

  memset(cBT_setting, 0x00, SET_SETTING_BUFF_SZ );
  eBSP_Set_radio_uart_to_callback();

  cBT_Rcvd_Settings = calloc(SETTINGS_BUFF_SZ, sizeof(char));
  if(cBT_Rcvd_Settings == NULL)
  {
    System_abort("Radio settings buffer failed allocation");
  }

  memcpy(cBT_setting, "SET BT\r\n", strlen("SET BT\r\n"));
//  Task_sleep(1000);  //With this delay in the code works at 1382400

  i = UART_write(sRadio_UART_handle, cBT_setting, strlen(cBT_setting));
  if(i == 0)
  {
    System_abort("Radio request settings not sent");
  }

  UART_read(sRadio_UART_handle, (uint8_t *)cBT_Rcvd_Settings, SETTINGS_BUFF);

  for(i = 0; i<30; i++)
  {
    if(strstr(cBT_Rcvd_Settings, "SET\r\n) != NULL)
    {
      eEC = ER_OK;
      break;
    }
    else
    {
      Task_sleep(100);
      eEC = ER_FAIL;
      continue;
    }
  }
  
  //cancel the read callback mode since the entire buffer was received and an overflow notification is not needed
  UART_readCancel(sRadio_UART_handle);

  eEC = eParse_Radio_Settings(cBT_Rcvd_Settings);
  
  if(eEC == ER_FAIL)
  { 
    //radio not set, perform in-depth setup
  }
  else
  {
    //radio pre-set, continue to application
  }

  //free the receive buffer
  free(cBT_Rcvd_Settings);
  return eEC;
}

I think the UART_readCancel in that code snippet is only there to handle the case where the radio doesn't reply in time.

It looks like the code starts a callback-mode read, then spins in a loop waiting to see the response in cBT_Rcvd_Settings. If the response isn't there yet it waits 100 ticks and tries again. If the response hasn't arrived after 30 checks (30000 ticks) then the code gives up waiting, and then it needs to cancel the read which is still pending. If the read did succeed then the UART_readCancel does nothing.

To be honest, this is bad example to follow. It would have been better to use the readTimeout parameter in UART_Params to let the read finish early (I think that would work in blocking mode, or implement a similar timeout in the code with a custom callback that posts a semaphore.

EDIT: Just correcting my comment about readCancel being unnecessary when the read is successful. In fact it is required, because a completed read leaves UART RX enabled so that any further incoming bytes are saved in the RX FIFO. This is to allow continuous reading without bytes being lost between UART_read calls. The CC26XX-specific documentation says that a successful UART_read should be followed by another UART_read to continue receiving, or UART_readCancel to stop.