• State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 41 subscribers
  • Views 504 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

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.

CC3100MODBOOST: recv() doesn't return when socket is closed

Patrick Voelker
Intellectual 590 points
Part Number: CC3100MODBOOST
Other Parts Discussed in Thread: CC3200

I'm using the CC3100MODBOOST board in transceiver mode attached to another board for development.  When receiving a socket error, I close the socket while in the context of the socket event handler sl_SockEvtHdlr().  When the socket is closed, the thread waiting to receive data on that socket remains blocked on the recv() call.

I expected the recv() to abort and return.

What's the best way to handle this situation?  Can I force recv() to return another way?

FW and driver versions:

ID(67108864) FW(31.1.5.0.2) PHY(1.0.3.37)
NWP(2.11.0.1) ROM(13107) HostDrv(1.0.1.11)

  • 0
    Guru 73215 points

    Hi,

    Host driver CC3200/C3100 devices is not designed to be able deal with sl_ API call from asynchronous event or interrupt context. You should call sl_ APIs from thread context only and use asynchronous event for signalisation for your threads.

    In yours case you should call close() from same thread as you call recv() after you get error response from recv() API call.

    Jan

  • 0 in reply to Jan D
    Intellectual 590 points

    I'm not sure if you caught it but this is a TX error event that occurs while another thread is sitting on a recv() for that same socket.  There is no error returned from the recv.  In fact, I continue to receive raw wifi messages without error in transceiver mode even though there has been a TX error event.

  • 0 in reply to Patrick Voelker
    Intellectual 590 points

    Further followup: The call to the socket close _is_ occurring in thread context.  It's the spawn context for the _SlAsyncEventGenericHandler.  How do you know that a socket can not be closed in this context?  Can you point me to that part of the documentation?

  • 0 in reply to Patrick Voelker
    Intellectual 590 points

    Additional further followup:  The call to sl_Close() doesn't appear to return at all when called from _SlAsyncEventGenericHandler.  I hadn't realized this before.

  • 0 in reply to Patrick Voelker
    Guru 73215 points

    Hi,

    Yes, I said at my first answer, you could not call sl_ API from asynchronous handler, unless you don't want to see unexpected behaviour.

    Generally is not a best approach to call recv() or send() from different threads with same socket. In case you not have concern to power consumption is a preferable way to use one task for each opened socket and use non-blocking sockets.

    Jan

  • 0 in reply to Jan D
    Intellectual 590 points

    Looks like I will have to do some rearchitecture to leverage non-blocking sockets.  Thanks for the pointers.