This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

What is the non-blocking behaviour of HCI_CMND_BSD_SELECT

If I set a timeout of one second and ask the command to not block what is the behaviour?

Will the command not respond for an entire second if there is nothing available, and then respond with 0 items

How about if there is a single socket that can provide data. 

Will the call return for that single socket immediately, or will it still wait for 1 second?

If it does the former, And if I mix read and write handles, does it return immediately if data can be written even if it can't be read, or does it wait?

  • Hi Anthony,

    Can you please help me to clarify about the non-blocking behavior that you are referring to? Is it the select command that you expect to run in a non-blocking manner? If yes, then select cannot be used in a non-blocking manner as such, but you can apply a required logic based on a very less time-out value.

    Yes, the command will wait until either some data is available or if a time-out occurs. On time-out the select API will return a 0.

    This is applicable for the single socket as well. And it will return for that socket only when data is available. If not, it will wait for the timeout.

    Can you please explain a bit more about the last scenario? In case of write handles, how are you planning to break the 'select'? I mean what would be the trigger for select to return immediately?

    Thanks & Regards,
    Raghavendra

  • Hi Anthony,

    To clarify a bit more. By non-blocking, I meant something in lines of the non-blocking behavior of 'accept' and 'recv'. From the API perspective, the 'select' is blocking (time-out has no relevance) when timeout==NULL. And it is non-blocking when it based on a time-out value.

    Thanks & Regards,
    Raghavendra

  • Raghavendra Shenoy Mathav said:

    Hi Anthony,

    Yes, the command will wait until either some data is available or if a time-out occurs. On time-out the select API will return a 0.

    Remember, I'm not using your driver.  I'm sending the commands myself.

    My question is, if I send a command to SELECT, when will the command send a response?

    From above, it looks like either when there is some data or when the timeout occurs.

    In the case where there is no data, can I send other commands to the CC3000.  I assume I must wait.

    Secondly, if data can be sent on a socket, I assume SELECT will return early even if none can be received.  Is that correct?

  • " My question is, if I send a command to SELECT, when will the command send a response?

    From above, it looks like either when there is some data or when the timeout occurs. "

    Anthony,

    Your assumption in the second line above is correct.  I set my timeout for 5000uS, so that either way I am not waiting long at all and it works well for me.  I am not using TIs driver either.  I do wait for the response before moving on to the next command though.  

    I have found that it is a good idea to wait for the response to everything from the chip and do not let commands interrupt each other.  This command, among others, may be an exception and I would be interested to know from TI whether you have to wait for the response before sending another command.  You would have to handle those responses coming back in a different order every time either way though.

    Either way it seems to me that this somewhat slows down the transmission rate as you basically have to poll for data.  I would like to see the module set the int flag when new data comes so my int routine could handle it.  Hopefully TI considers this when designing the next module.

    Hope this helps.

    Chad