How can the client actively disconnect without transmitting data #4998

Disconnect? Just call uv_close().

uv_shutdown() is for when you want to signal you're going to close one end of the connection for reading or writing, but that's unnecessary if you want to disconnect immediately.

断开连接？只需调用 uv_close() 即可。

uv_shutdown() 用于发出即将关闭读取或写入连接的一端的信号，但如果您想立即断开连接，则没有必要这样做。

This is my implementation code

Wild guess: you're freeing or reusing the uv_tcp_t's memory before the close callback is called.

Wild guess: you're freeing or reusing the uv_tcp_t's memory before the close callback is called.

No, all memory releases are done in callback functions. I have checked and found that it is not a problem with my code, but rather an internal issue with the libuv library

You're hitting an assert in libuv but that's not an internal issue, that's libuv telling you the handle got corrupted somehow.

You're hitting an assert in libuv but that's not an internal issue, that's libuv telling you the handle got corrupted somehow.

How can I explain why my program links to the released libuv library and still runs normally with the same code?

Because the release build doesn't have debug asserts enabled of course.

Because the release build doesn't have debug asserts enabled of course.

After multiple verifications, I found an issue where the client, after successfully connecting to the server, actively disconnects using uv_close in two situations without transmitting data. Repeatedly connecting and disconnecting the same uv_tcp_t object to the server within 10 times can cause an exception to pop up. This situation occurs when debugging or releasing when bored.

Because the release build doesn't have debug asserts enabled of course.

`static void XXXXXXX::AsyncServerThread(void arg)
{
uv_loop_t loop=static_cast<uv_loop_t*>(arg);

uv_mutex_init(&mutex);
uv_cond_init(&cond);

while (1) {

    uv_mutex_lock(&mutex);

    thread_state=uv_run(loop, UV_RUN_DEFAULT);

    while (thread_state==THREADSTATE::WAIT){
        uv_cond_wait(&cond,&mutex);
    }

    uv_mutex_unlock(&mutex);

    if(thread_state==THREADSTATE::STOP)
        break;
}

thread_state=THREADSTATE::START;

uv_mutex_destroy(&mutex);
uv_cond_destroy(&cond);

}`My client event loop is placed in a separate thread, separate from Qt's event loop

Are you accessing the uv_tcp_t (or any handle except uv_async_t) from multiple threads? Don't do that.

Are you accessing the uv_tcp_t (or any handle except uv_async_t) from multiple threads? Don't do that.

The client has only two threads, the qt main event loop thread and the libuv event loop thread (running the uv_run() function). The main thread accesses the uv_tcp_t object to connect and disconnect from the server. If two threads are not opened, what should be done for the event loops of uv and qt?

Are you accessing the uv_tcp_t (or any handle except uv_async_t) from multiple threads? Don't do that.

I don't quite understand this document. How to embed other event loops https://docs.libuv.org/en/v1.x/guide/eventloops.html

Use a uv_async_t and a message queue (e.g. linked list protected by a mutex) to send messages from your qt thread to the uv thread. That is:

1. from the qt thread: lock mutex, push message onto list, unlock mutex, call uv_async_send
2. in the uv_async_t callback: lock mutex, pop message from list, unlock mutex, process message

Read the uv_async_t/uv_async_send documentation carefully.

Use a uv_async_t and a message queue (e.g. linked list protected by a mutex) to send messages from your qt thread to the uv thread. That is:

1. from the qt thread: lock mutex, push message onto list, unlock mutex, call uv_async_send
2. in the uv_async_t callback: lock mutex, pop message from list, unlock mutex, process message

Read the uv_async_t/uv_async_send documentation carefully.

I see! No wonder I said the server can automatically shut down normally, why can't the client? The server (which is a command-line program) performs all operations on the main thread. Thank you very much for your answer. Thank you very much for your hard work.

Converted to a discussion as this wasn't actually a bug report.