Nolocal close #434
Nolocal close #434
Conversation
yellowhatter
added
enhancement
include/zenoh/api/close.hxx
Outdated
| @@ -0,0 +1,38 @@ | |||
|
|
|||
| // | |||
| // Copyright (c) 2024 ZettaScale Technology | |||
There was a problem hiding this comment.
Should it be 2025 ?
| /// A function to receive close handle. If set, the close operation will be executed concurrently | ||
| /// in separate task, and this function will receive a handle to be used for controlling | ||
| /// close execution. | ||
| std::function<void(CloseHandle&&)> out_concurrent = nullptr; |
There was a problem hiding this comment.
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 ?
There was a problem hiding this comment.
I'd need an overload by return value to do this. And this is not available in C++ :)
There was a problem hiding this comment.
Because there is still a common version of close that doesn't return handle
There was a problem hiding this comment.
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 ?
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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
No description provided.