Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make all sync mechanisms public #309

Merged
merged 5 commits into from
Jan 11, 2024

Conversation

jean-roland
Copy link
Contributor

Some system-abstracted functions where public, like z_time and z_clock while the multi-thread ones z_task, z_mutex and z_condvar were not. This PR fixes this inconsistency that was noted in #271.

Note that 2 systems are not fully covered (functions and types are stubs):

  • Arduino/opencr has no support for task, mutex and condvar
  • FreeRTOS has no support for condvar

Copy link

@github-advanced-security github-advanced-security bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Cppcheck (reported by Codacy) found more than 20 potential problems in the proposed changes. Check the Files changed tab for more details.

@p-avital
Copy link
Contributor

p-avital commented Jan 8, 2024

If we want them public, can it at least be restricted to zp namespace? Otherwise zenoh-c will also have to expose these

@Mallets
Copy link
Member

Mallets commented Jan 8, 2024

I agree with @p-avital . Let's expose them public but with the zp_ prefix.

@jean-roland jean-roland force-pushed the ft_sync_public branch 2 times, most recently from 0e9b446 to 474e9b6 Compare January 8, 2024 14:07
@jean-roland
Copy link
Contributor Author

jean-roland commented Jan 8, 2024

But wasn't Zenoh C supposed to eventually or already expose at least some of these? Also it would be weird to have some of them in z_ and some in zp_ so here are all the mechanisms concerned:

  • z_random
  • z_malloc/z_free
  • z_task
  • z_mutex
  • z_condvar
  • z_sleep
  • z_clock
  • z_time

@Mallets
Copy link
Member

Mallets commented Jan 8, 2024

But wasn't Zenoh C supposed to eventually or already expose at least some of these? Also it would be weird to have some of them in z_ and some in zp_ so here are all the mechanisms concerned:

  • z_random
  • z_malloc/z_free
  • z_task
  • z_mutex
  • z_condvar
  • z_sleep
  • z_clock
  • z_time

I think we need a table checking what is supported and what not. The real API I'm quite confident restricting to zp_ only for now is z_task since zenoh-c is a binding to async Rust. We might expose it in the future though. Comments?

@jean-roland
Copy link
Contributor Author

Agreed for z_task, and beside z_random that is not used in the examples, exposing the others on zenoh-c should allow the zenoh-pico examples to run on zenoh-c.

typedef void *_z_task_attr_t; // Not used in ESP32
typedef pthread_mutex_t _z_mutex_t;
typedef pthread_cond_t _z_condvar_t;
typedef TaskHandle_t z_task_t;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the type should be called zp_task_t.

typedef pthread_mutex_t _z_mutex_t;
typedef pthread_cond_t _z_condvar_t;
typedef TaskHandle_t z_task_t;
typedef void *z_task_attr_t; // Not used in ESP32
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I believe the type should be called zp_task_attr_t.

typedef void *_z_condvar_t;
typedef void *z_task_t;
typedef void *z_task_attr_t;
typedef void *z_mutex_t;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems that z_mutex_t and z_condvar_t are not available in zenoh-c.

@Mallets
Copy link
Member

Mallets commented Jan 9, 2024

Before merging, can you please confirm that:

z_malloc/z_free
z_mutex
z_condvar
z_sleep
z_clock
z_time

are all supported in zenoh-c?

@jean-roland
Copy link
Contributor Author

None of these types are currently supported in zenoh-c

@Mallets
Copy link
Member

Mallets commented Jan 9, 2024

Ok, then let's stick to zp_xxx namespace.
Once those functions are added to zenoh-c we can always do a #define zp_xxx z_xxx for backward compatibility.

@Mallets Mallets merged commit d3a631f into eclipse-zenoh:master Jan 11, 2024
47 checks passed
@jean-roland jean-roland deleted the ft_sync_public branch January 11, 2024 16:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants