Attempt to solve the problem of thread lifecycle exceeding structure#285
Attempt to solve the problem of thread lifecycle exceeding structure#285jokemanfire wants to merge 1 commit intocontainerd:masterfrom
Conversation
|
#284 |
a57a7ce to
2f3dee2
Compare
| pub async fn start(&mut self) -> Result<()> { | ||
| // In order to ensure compatibility, this interface has been added and will wait for the service thread to end indefinitely | ||
| // This will not cause thread leak. | ||
| pub async fn serve(&mut self) -> Result<()>{ |
There was a problem hiding this comment.
Consider consume the Server here? like tonic
There was a problem hiding this comment.
That means the server will be block , unless you run it in a tokio task , and if you want to control the server's lifetime , the caller must think about it. So we need not control the thread lifetime now in lib.
| } | ||
| trace!("listener exit."); | ||
| }); | ||
| if do_wait{ |
There was a problem hiding this comment.
Why don't we discard the spawn when do_wait == true. Only stop using tokio task can solve the lifetime problem in my opinion.
There was a problem hiding this comment.
Sure, If we design it this way, we need to send signals in drop and receive signals in do-wait and try to exit the thread. If it's like now, we can maintain consistency with tonic in terms of external interface performance, and we need not to care about the task leak , to the outside world, the lifecycle of serve'struct and the tokio task is consistent, we need not to care the thread now, but both methods are feasible for me.
|
@Tim-Zhang take a look , i think this will be great. |
1.add drop trait for server 2.add ut in async server 3.add it in async example Signed-off-by: jokemanfire <hu.dingyang@zte.com.cn>
|
Hi @jokemanfire, I found a bug recently, could this #298 fix the lifetime problem? |
server's lifetime's problem. There's thread leak.