Clearing pending events on Socket instances

[tommikas]

In blocking mode, for example:

1. create, open and bind a UDP socket
2. attach the socket to a callback function
3. receiving a UDP packet on the listening port triggers the callback
4. call recvfrom to retrieve the data
5. an event seems to be pending, which blocks any subsequently received UDP packets from triggering the callback

In step 4, it seems that the _pending flag is cleared before socket_recvfrom() is called, which in turn triggers the event callback again setting the _pending flag again.

In non-blocking mode the recvfrom call in step 4 also triggers another callback, but a 2nd recvfrom call (which returns NSAPI_ERROR_WOULD_BLOCK) clears the flag, allowing new events to trigger the callback.

The same thing seems to happen with at least UDPSocket::recvfrom, TCPSocket::recv and TCPServer::accept.

Is this the intended behaviour? Have to use non-blocking sockets and make the call twice to clear the pending event to be able to receive new ones?

[0xc0170]

cc @geky

[geky]

Thanks for raising the issue, unfortunately socket operations are currently disallowed from the Socket::attach function. Much like the existing attach functions in the mbed hal, this attach function may be in an interrupt context. This prevents long-running functions (including the mutexes used to synchronize the socket interface).

I posted an in depth explanation of the issue and available workarounds over here https://github.com/ARMmbed/mbed-os-morpheus/issues/167, here's the current options for working around the interrupt context:

At the moment, decoupling from interrupts is unfortunately frustrating for users, since we don't provide standard utilities to do so. We are currently looking into what these utilities might look like and how they might integrate with mbed-os.

There are a few options currently available:

1. Use the blocking API

   The NetworkSocketAPI was originally intended to be used only in blocking mode, with multiple threads for multiple sockets. This avoids the issue of decoupling from interrupt contexts, and is simpler in the common case.

   This biggest issue with this option is the cost of creating multiple threads, which is especially noticable when using a socket as a server.

2. Use semaphores to signal pending threads

   This is a good simple solution when dealing with multiple sockets:
   https://developer.mbed.org/teams/NetworkSocketAPI/code/HelloLWIPInterfaceNonBlocking/file/6563866f9466/main.cpp

   This lets you build equivalent functionality to BSD's select call, however composing different APIs can get complicated fairly quickly unless you execute each module in a separate thread.

3. Use an event loop

   This is the most flexible option, although we don't have a standard implementation built into mbed-os. There is a prototype of an rtos-compatible event loop library being worked on here: https://github.com/armmbed/mbed-events

[tommikas]

I'm aware that the callback function may run in interrupt context and shouldn't do anything too heavy. In retrospect I could've made it clearer, but step 4 in my original comment happens from thread context, not directly from the callback.

Anyway, just to be clear, it is intended behaviour that the call has to be made twice to clear the pending event? (In non-blocking mode and from thread context of course.)

[geky]

Ah, I think I understand now.

This isn't disallowed behaviour, the attach function is defined to allow spurious callbacks to simplify network stack implementations:

The specified callback will be called on state changes such as when the socket can recv/send/accept successfully and on when an error occurs. The callback may also be called spuriously without reason.

That being said, thanks for pointing this out. We should probably move that flag so the event only triggers once for efficiency reasons.

[tommikas]

It's a pretty minor thing though.

I was also thinking that arguably the application should be making the call until it returns NSAPI_ERROR_WOULD_BLOCK either way, in case multiple packets were received while the 'event pending" flag was up.
As it currently works sort of enforces that. Whether it should or not is a different matter...