embObjLib: in ethReceiver set receiving thread as non-blocking also on Windows

[traversaro]

In the embObjLib, the ethReceiver is the thread dedicated to receive the UDP messages sent by the ETH boards (such as EMS, MC4_PLUS).

On Linux and macOS, this socket is set in non-blocking mode by the code:

    int flags = 0;
#ifndef WIN32
    flags |= MSG_DONTWAIT;
#endif

in https://github.com/robotology/icub-main/blob/v2.6.2/src/libraries/icubmod/embObjLib/ethReceiver.cpp#L177-L180 .

However, there is no such flag on Windows, so in the Windows case the recv call in https://github.com/robotology/icub-main/blob/v2.6.2/src/libraries/icubmod/embObjLib/ethReceiver.cpp#L200 was actually blocking. I am not super-expert of this part of code, so I am not sure what was the effect of the code being non-blocking there on Windows, but for sure I experienced a related problem: when I was launching a yarprobotinterface with a embObjMotionControl device, during the close of the robotinterface, the close was hanging with message:

[INFO] |yarp.os.RFModule| [try 1 of 3] Trying to shut down.
[WARNING] Interrupt # 1 # received.
[INFO] Interrupt received. Stopping all running threads.
[INFO] |yarp.os.RFModule| RFModule closing.
[INFO] interrupt1 phase starting...
[INFO] interrupt1 phase finished.
[INFO] shutdown phase starting...
[INFO] Closing device iiv-x-lm1_mc

Instead, by making the socket non-blocking also on Windows, the program exists correctly. In theory we may want to use the recv_socket->enable(ACE_NONBLOCK); also on Linux and macOS in place of flags |= MSG_DONTWAIT; for uniformity and cleaning the code, but as I can't extensively test this part of the code and as it is of critical importance, for now I just made the modification on Windows, without any change for Linux and macOS.

[traversaro]

fyi @marcoaccame

[pattacini]

In theory we may want to use the recv_socket->enable(ACE_NONBLOCK); also on Linux and macOS in place of flags |= MSG_DONTWAIT;

What do you think about it, @marcoaccame?
It seems quite a sensible suggestion.

We could address it separately.

[marcoaccame]

In theory we may want to use the recv_socket->enable(ACE_NONBLOCK); also on Linux and macOS in place of flags |= MSG_DONTWAIT;

What do you think about it, @marcoaccame? It seems quite a sensible suggestion.

We could address it separately.

I think that it is a good idea. It could be a small uniformization to do before we go deeper into robotology/icub-tech-support#1861 (comment) that touches the receiver as well

[pattacini]

Hi @marcoaccame, can I merge this patch in the meantime?

[marcoaccame]

OK, thanks @traversaro