Support waiting on condition variable until a specific time point

[bjsowa]

This is my proposal for supporting waiting on condition variable till a specific time point. For now, I only implemented it for unix. If this gets approved, I can implement this function for the rest of the ports.

[github-actions]

PR missing one of the required labels: {'new feature', 'enhancement', 'dependencies', 'internal', 'documentation', 'breaking-change', 'bug'}

[jean-roland]

Hello @bjsowa, thanks for your contribution. Just to make sure since your PR is in draft, do you want us to give it a look as is?

[bjsowa]

Hello @bjsowa, thanks for your contribution. Just to make sure since your PR is in draft, do you want us to give it a look as is?

Yes, I would like to discuss the interface first. Once it's approved, I will implement it for different ports

[jean-roland]

OK then we'll check this a bit later, when we have time™.

[jean-roland]

Hey @bjsowa, the approach looks fine to us.

Just a note, since we're in the process of releasing Zenoh 1.0, we'll only be able to merge the changes after the release.

[github-actions]

PR missing one of the required labels: {'dependencies', 'enhancement', 'breaking-change', 'new feature', 'bug', 'internal', 'documentation'}

[github-actions]

PR missing one of the required labels: {'dependencies', 'enhancement', 'documentation', 'new feature', 'breaking-change', 'internal', 'bug'}

[github-actions]

PR missing one of the required labels: {'bug', 'new feature', 'breaking-change', 'dependencies', 'internal', 'documentation', 'enhancement'}

[github-actions]

PR missing one of the required labels: {'internal', 'enhancement', 'bug', 'new feature', 'breaking-change', 'dependencies', 'documentation'}

[github-actions]

PR missing one of the required labels: {'documentation', 'enhancement', 'bug', 'dependencies', 'breaking-change', 'new feature', 'internal'}

[github-actions]

PR missing one of the required labels: {'bug', 'dependencies', 'breaking-change', 'internal', 'enhancement', 'new feature', 'documentation'}

[bjsowa]

I'll try to finish this PR after #821 gets merged

[bjsowa]

This is ready for review but take in mind I only tested it on unix and freertos ports. I'm especially not sure about mbed, windows and emscripten ports.

[sashacmc]

@bjsowa thanks for the PR!
IMHO, it would be better to return a timeout error as a new z_result_t code:

• Simpler API: Users can handle all outcomes (errors, timeouts, success) directly via the return value, removing the need for a separate timeout flag.
• Consistency: Aligns with common practices (e.g., ETIMEDOUT in POSIX), ensuring all exceptional conditions are uniformly represented by z_result_t.
• Cleaner Code: Simplifies error handling, reduces complexity, and improves code readability and maintainability.

[sashacmc]

Last nit,
others LGTM

[sashacmc]

Suggested change

	if (clock->tv_nsec >= 1000000000) {
	clock->tv_sec += 1;
	clock->tv_nsec -= 1000000000;
	}
	if (clock->tv_nsec >= 1000000000) {
	clock->tv_sec += clock->tv_nsec / 1000000000;
	clock->tv_nsec %= 1000000000;
	}

This will be more accurate.

[bjsowa]

Is it really necessary? Assuming the passed clock is valid (tv_nsec < 1e9) there should be at most one second that we will have to carry from tv_nsec to tv_sec