Single core clients

[giafranchini]

Hi, first of all thank you very much for the effort in this project. I am currently trying to integrate pico-ros functionalities in an zenoh-pico application running on an Arduino Mega.

Since this is a single core board, I need to compile zenoh-pico with Z_FEATURE_MULTI_THREAD=0, and so read and lease task for the client are not defined, see for example: https://github.com/eclipse-zenoh/zenoh-pico/blob/7263484566b89ce7e0f9fe3d80d7b787e3add68b/src/api/api.c#L2211-L2224, and I need to manually call zp_read and zp_send_keep_alive from my application code.

I think it would be useful to add a functionality to define if using a single-core board, and provide ways to call read and keep alive directly from pico-ros. Just as an example, in my application I added the following to picoros.c:

z_result_t picoros_send_keep_alive() {
    return zp_send_keep_alive(z_loan(s_wrapper), NULL);
}

z_result_t picoros_read() {
    return zp_read(z_loan(s_wrapper), NULL);
}

[g4sp3r]

Hi @giafranchini, that's great! Thanks for opening this issue. I was planning to try the same thing but didn't come to it yet.

I think your suggestion to handle single-threaded case in pico-ros makes sense.

Checking zenoh-pico examples I see the following code:

        zp_read(z_loan(s), NULL);
        unsigned long elapsed_ms = z_clock_elapsed_ms(&pulse_time);
        if (elapsed_ms >= (Z_TRANSPORT_LEASE / Z_TRANSPORT_LEASE_EXPIRE_FACTOR)) {
            pulse_time = z_clock_now();
            zp_send_keep_alive(z_loan(s), NULL);
            zp_send_join(z_loan(s), NULL);
        }

It seems like we would also need the zp_send_join call.

I think we could check for Z_FEATURE_MULTI_THREAD define and enable pico-ros single-threaded api.
For the api itself I see two options:

1. Wrap read, keep-alive and join functions and let the user handle it.
2. Implement whole of the above code in something like picoros_loop.

My sense, number 2 could be better since the user doesn't need to duplicate the above code block in each project, but number 1 could give more control if needed.

The only worry I have is with the options set as NULL in the examples. Currently I see only zp_read having the option single_read, but that could change in future. I think it's good to not limit the user with default options.
We could add the options arguments to wrapped calls or add all of them to picoros_loop as 3 arguments. Another way is to add them to picoros_interface_t structure, store them during init and then use them inside single-threaded api implementation.

What are your thoughts?
Do you see any case where the user would want to have finer control by having all three wrapped functions available?
Could you see any other potential issues with option number 2 and extending the interface structure?

[giafranchini]

Hi @g4sp3r, thanks for the quick reply.

It seems like we would also need the zp_send_join call.

About this, yes I agree. I did not implement it since my application uses unicast transport and apparently join task does not apply to this case: https://github.com/eclipse-zenoh/zenoh-pico/blob/6c30e0d8356d0455af76e0e81da4436a5140daab/src/transport/common/lease.c#L42-L59, but we should include it to maintain generality.

Could you see any other potential issues with option number 2 and extending the interface structure?

I do agree with your analysis. In general the user will have to call all the three functions, so a single wrap it's a nice idea. The only corner case that occurs to me is one where the user would like to call one of these at different rate or somewhere else in the code (but I am just a beginner in using zenoh-pico, so not sure if this can actually happen).

Again I agree with not limit the usage by passing NULL as option. Both ways are fine for me, once we agree on which path to follow.