Stopping http takes 1 second

Hello,

This is more a question than a real issue.

We are using uWebsockets to put up a minimal http server for REST api requests in our C++ code.
The code goes more or less like so:

uWS::App app;
AttachAllRouters(app);
app.listen(port,
           [this](auto* socket)
           {
             if(socket) {
               listenSocket = socket;
             } else {
               throw std::logic_error("Failed binding to port " + port);
             }
           });
app.run();
LOG(Http Backend event loop stopped);

All of this happens on a separate thread, but fully within that thread. listenSocket is a member of my class: us_listen_socket_t* listenSocket{nullptr};

When the time comes to close the program I call from the main thread:

    LOG("Stopping server");
    if(running.load())
    {
      us_listen_socket_close(NO_SSL, listenSocket);
    }
    LOG("socket closed");
    if(serverThread.joinable())
    {
      serverThread.join();
    }
    LOG("Exiting HTTPServer");

Running this gives me:

00:00:00:00.170 [StopServer]: Stopping server
00:00:00:00.170 [StopServer]: socket closed
00:00:00:01.018 [RunServer]: HTTP Backend event loop stopped
00:00:00:01.018 [StopServer]: Exiting HTTPServer

So it takes almost a full second for the socket to close (or at least for app.run() to exit after us_listen_socket_close returns).
I can confirm that on this time, no http calls are active, nobody is communicating to the http.

This 1 second might not seem like a big issue and it is not in production. But we have a series of acceptance tests. For each of these tests, the http server gets build and destroyed again. So the 1 seconds goes times 100. 80% of our acceptance tests time is just waiting for the httpserver to go down again.

Is this timeout a setting we can influence? Can we reduce it (even if only during the testing)? Or can you safely reduce it in a next release?

Thanks

Start with the us_listen_socket_close call and the app.run entry point, then reproduce the shutdown timing described in the acceptance tests. Trace why app.run takes about one second to exit after the socket closes and determine whether that delay is configurable or safely reducible; done means documenting the setting or reducing the repeated teardown wait without breaking shutdown.