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.

non-blocking recv -- select() vs SOCKOPT_RECV_TIMEOUT

hi,

i don't want to block indefinitely on a recv() call, so i am planning to use select()....

question -- doesn't select() "block", as do all other operations in the socket API???

and, since there appears to be a minimum timeout value of 5ms applied, won't i be "blocked" for quite a while???

really, i'd like to *quickly* determine whether a recv would succeed, and then go off and do something else if this is not the case....

i noticed mention of SOCKOPT_RECV_TIMEOUT in setsocketopt()???  could i effective have "polling" by setting this value to 0???

thanks,

bob.

  • Hi Bob,

    We are looking on your question and we will provide feedback soon.

    Regards,

    Alon

  • Bob,

    At the moment the set of APIs provided are blocking. select blocks as well, but it allows you to manage multiple sockets.

    I will check whether setting the timeout to 0 will result in the blocking function to return immediately.

    Regards,
    Gustavo

  • hi gustavo,

    thanks for checking into this....  the select() function in the host library sets the timeout value to SELECT_TIMEOUT_MIN_MICRO_SECONDS (which is 5000); i can obviously change this, as i have the source code....

    the real question is what the underlying c3000 function does, invoked by the HCI_CMND_BSD_SELECT cmd???   if in fact the c3000 returns "promptly" with the results of the select, then i'm fine with this....

    bob.

  • Hi Bob,

    It is not recommended to change teh source code of Host Driver. The CC3000 device does not support less than SELECT_TIMEOUT_MIN_MICRO_SECONDS.

    The device will be waiting for timeout defined and than return from the select function.

    So as Gustavo stated CC3000 select implementation is actually also blocking.

    Regards

    Igor

  • Hi Igor,

    So, my application will be "stuck" for 5ms waiting for select() to in fact tell me there is no input???

    The whole point of select() is to enable an application to (quickly) poll the state of various sockets, and then go off and doing something else (or go to sleep and not waste power)....

    5ms seems like an eternity to be polling!!!

    Could you investigate alternatives for me???   I noticed that you support SOCKET_RECV_TIMEOUT....  how does that work, and what is the "minimum value" i can use???

    Bob.

  • Hi Bob,

    Thanks a lot for your input. I do understand your point - yet this is what we got for CC3000 for now.

    I will take a look on SOCKET_RECV_TIMEOUT...

    Regards,

    Igor

  • Bob,

    One immediate workaround is for the MSP430 to use interrupts so that it can handle other things while select() is running.

    Regards,
    Gustavo