Break blocked function recv() using task_ready(*)

[CaesarI]

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

[Martin_]

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

[stevejanisch]

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) ) ;

[Martin_]

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();
    }

[CaesarI]

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?

[Martin_]

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 */
  }
}

[CaesarI]

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

[CaesarI]

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