Break blocked function recv() using task_ready(*)

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Break blocked function recv() using task_ready(*)

1,255 Views
CaesarI
Contributor III

Hi,

we are using MQX 3.8.1, IAR 6.4.02 and RTCS.

Is the usage of task_ready(*) allowed to break blocked functon like recv()?

We want to use this cause the automatic connection abortion of RTCS using OPT_CONNECT_TIMEOUT does'nt work all the time - unused connections are always active.

Our test result gave UNHANDLED INTERRUPT 0x41 in TCP/IP task... How may we handle this?

regards,

CAESAR

7 Replies

673 Views
Martin_
NXP Employee
NXP Employee

recv() will be non-blocking if a streaming socket has receive-nowait option true (OPT_RECEIVE_NOWAIT).

0 Kudos

673 Views
stevejanisch
Contributor IV

Can you be more specific on how to code OPT_RECEIVE_NOWAIT...

I would suspect it is done with setsockopt and you pass the socket as the first argument... the options for arguments 2 and 3 as well as what you should be doing with the option pointer in 4 is where I am confused.

I am trying this:

nSock = accept( nListenSock, NULL, NULL ) ;

ui32Option = RTCS_MSG_NONBLOCK ;

ui32Error  = setsockopt( nSock, SOL_TCP, OPT_NOWAIT, &ui32Option, sizeof(ui32Option) ) ;

0 Kudos

673 Views
Martin_
NXP Employee
NXP Employee

Example:

uint_32 option;

    /* Set socket options */

    option = TRUE;

    retval = setsockopt(client_sock, SOL_TCP, OPT_RECEIVE_NOWAIT, &option, sizeof(option));

    if (retval != RTCS_OK)

    {

        fputs("Fatal Error: Unable to set socket options Rx.", stderr);

        _task_block();

    }

673 Views
CaesarI
Contributor III

We want to have recv() like bloccking function, cause normal we want to wait for receive and we need processor performance to let work other tasks. But in some cases (especially connenstion loss) we want to stop waiting for receive - in this case we call now 'task_ready(*)'  (in an other task) and it works unfortunately not. The question is: Is the usage of task_ready(*) allowed to break blocked functon like recv()? Whats the matter with UNHANDLED INTERRUPT 0x41 in TCP/IP task... How may we handle this?

Do you know an other way to break the recv()-waiting? Or do you know why automatic connection abortion of RTCS using OPT_CONNECT_TIMEOUT doesnt work every time?

0 Kudos

673 Views
Martin_
NXP Employee
NXP Employee

I am not aware the OPT_CONNECT_TIMEOUT doesn't work every time. I thought that it works, it is just long time (8 minutes default). Maybe you've tried to make this time shorter ? There is a minimum of 180.000 milliseconds.

I wouldn't personally use _task_ready() to unblock recv(), as recv() dosn't expect it can be activated this way. At low level it sends a message to RTCS task and blocks, expecting activation by reception of some data. But if the data are not there, maybe it accesses an uninitialized pointer or something like that.

You could have recv() non-blocking and block your task to wait for receive at application level, like example below:

while(cnt_app_timeout < MAX_TIMEOUT)
{
  count = recv();
  if(RTCS_ERROR == count)
  {
   ...
  }
  else if(0 == count)
  {
   cnt_app_timeout++;
   _time_delay(200); /* let other tasks run */
  }
  else
  {
   /* handle received data */
  }
}

673 Views
CaesarI
Contributor III

Thx Martin,

now we use RTCS_selectset to work timed by blocked access..

We tryed to use OPT_CONNECT_TIMEOUT with more than 3 minutes, cause we already read the value range.

We listened on the ethernet by wireshark to check the connenction for any transfer, but there was no transfer and the connection was'nt aborted by RTCS automatic. This was a observation we made more than once, but not every time, so we had to use a secure way...

Caesar

0 Kudos

673 Views
CaesarI
Contributor III

Does no one used such method to reenter a task waiting in a blocked function?

0 Kudos