Solving excessive read task CPU usage and question on TCP connection state handling

[42dot-bongjun-hur]

Describe the release item

In Zenoh-Pico's unicast transport, the read thread consumes excessive CPU resources when there is no data to receive. This occurs because the thread is busy-waiting on a non-blocking socket, immediately retrying the read operation in a tight loop. To fix this, I propose adding a short sleep (z_sleep_ms(1)) after an unsuccessful read to allow the CPU to yield to other tasks. This simple change will significantly reduce CPU usage, which is critical for resource-constrained embedded systems.

zenoh-pico\src\transport\unicast\read.c line 358:

            size_t to_read = 0;
            // Retrieve data
            if (!_z_unicast_client_read(ztu, curr_peer, &to_read)) {
                // [Proposed Change] Add a small delay to prevent busy-waiting
                z_sleep_s(1);
                continue;
            }

Additionally, I would like to know how a Zenoh-pico client can detect when its TCP connection to a broker has been terminated. What is the proper way to handle this state in the client application?

[jean-roland]

Hello @42dot-bongjun-hur, the read thread was designed to use blocking sockets, adding a sleep would introduce a latency as high as the sleep so it's not an acceptable solution.

What platform are you using? If for some reason you are forced to use non-blocking socket, you can try setting your zenoh-pico nodes as unicast peer as they handle non-blocking sockets.

For lost connection, zenoh-pico has the ability to try to reconnect (Z_FEATURE_AUTO_RECONNECT).

[42dot-bongjun-hur]

Hi @jean-roland, Thank you for the clarification. I understand the issue with adding sleep(), and your explanation makes sense. (I used "lwIP+FreeRTOS" platform)
Regarding reconnection, since the design assumes blocking sockets by default, I also think it is appropriate for the _zp_unicast_read_task() operation to detect when the broker has been shut down and return an error in that case. From my perspective, the AUTO_RECONNECT feature you mentioned seems like a broader recovery solution. My question is: when the TCP connection is lost, does the read task also return an error, or is it handled differently as part of the auto-reconnect process?

Looking at the code, if the buffer size is less than or equal to a certain value (e.g., 2), it simply returns false. This means that, regardless of whether the TCP connection has been closed or not, —even if _z_link_socket_recv_zbuf() returns SIZE_MAX— the function will keep returning false, and as a result, the _zp_unicast_read_task() will continue calling this function(_z_unicast_client_read()) indefinitely without ever exiting. Even though this is a blocking function, I would like to ask your opinion on whether it would be better to enhance this part to properly handle such situations.

static bool _z_unicast_client_read(_z_transport_unicast_t *ztu, _z_transport_peer_unicast_t *peer, size_t *to_read) {
    switch (ztu->_common._link._cap._flow) {
        case Z_LINK_CAP_FLOW_STREAM:
            if (_z_zbuf_len(&ztu->_common._zbuf) < _Z_MSG_LEN_ENC_SIZE) {
                _z_link_socket_recv_zbuf(&ztu->_common._link, &ztu->_common._zbuf, peer->_socket);
                if (_z_zbuf_len(&ztu->_common._zbuf) < _Z_MSG_LEN_ENC_SIZE) {
                    _z_zbuf_compact(&ztu->_common._zbuf);
                    return false;
                }
            }

[jean-roland]

I mean yeah there's a lot to do to improve this part regarding "unfortunate network events" in particular to make it more resilient/failproof in case of connection loss. Nobody is working on it currently so if you want to give it a try.