Nolocal close

[yellowhatter]

No description provided.

[DenisBiryukov91]

Should it be 2025 ?

[yellowhatter]

yes

[yellowhatter]

fixed

[DenisBiryukov91]

why not simply return close handle from close ? Or maybe even better make a separate close_async. Btw why can't we just only pass a timeout and move session close call to a separate async C++ task and just wait on its promise ?

[yellowhatter]

I'd need an overload by return value to do this. And this is not available in C++ :)

[yellowhatter]

Because there is still a common version of close that doesn't return handle

[DenisBiryukov91]

Close can always return handle, just in case of missing timeout it can be NULL, or as I suggested make a separate close_async. Also what is wrong with using C++ async task with blocking close and timeout ?

[yellowhatter]

The timeout is not tied to async close, it is ok to use it even with blocking close.

The pros to use "our" async close instead of making std::async:

• "our" close internals in Rust are covered with tests to work in atexit etc
• "our" close allows dropping a session once close handle is created and even before the actual close completed

[DenisBiryukov91]

Exactly, common sense tells that async does not need a timeout (because its non-blocking), so timeout should logically be an option only for a sync call (otherwise it does not make sense at all - is it amount of time that is provided to session to close itself ? then what happens if it does not manage to do it ? - it is not at all clear from the docs).

We can totally keep the behavior of rust, I just suggest to wrap handle into a promise over a simple function that waits on it to avoid creating unnecessary data types.

[yellowhatter]

I like the idea of close_async, but thus we need also to fix zenoh-c to have similar behavior. I will make this after the release and rmw code freee