session->close does not immediately flush the data

[RoyBellingan]

Based on https://github.com/Corvusoft/restbed/blob/master/documentation/example/HTTP_PERSISTENT_CONNECTION.md

I would expect that session->close even if not immediate would not be blocking until the method handler is finished.

So I would expect that something like
void get_intermittent_method_handler(const shared_ptr session) {
session->close(OK, "intermittent resource request", {{"Content-Length", "29"}, {"Connection", "close"}});
sleep(10);
}

Would be almost immediate.

The only way to get and write to the socket is via the https://github.com/Corvusoft/restbed/blob/master/documentation/example/WEB_SOCKET.md

session->upgrade

I think it should be possible to access the socket also in the normal flow, so is possible to send data to the client, and keep doing some work without having to move to other thread.

Also I am sorry to report that websocket too does not support this functionality (but here I understand would be a viable choice to offload back office work to another thread, still I think for most workload would just be a needless complexity)

[RoyBellingan]

I am currently adapting the internal logic and exposing it and... Well I think this is enought no ?

auto& socketImpl = session->m_pimpl->m_request->m_pimpl->m_socket;
auto& socket     = socketImpl->m_socket;
auto& strand     = socketImpl->m_strand;

string msg = "Ciao Belli";

string header = "HTTP/1.1 200 OK\r\n"
                "Connection: close\r\n"
                "Content-Length: " +
                to_string(msg.size()) + "\r\n"
                                        "\r\n";

string      response = header + msg;
const auto& buffer   = asio::mutable_buffers_1(response.data(), response.size());

auto callback = [&buffer, &socket](const error_code& error, size_t length) {
	//socket is closed by restbed somewhere somehow later, nothing to do except in case of error
};
asio::async_write(*socket, buffer, strand->wrap(callback));

I am currently testing it, and looks like is working fine

Edit, even a non modded restbed if I add a sleep(1);
Even if I put whatever number of worker, looks like the RPS reach a maximum around 200, I have no idea yet what that can mean and why is the case. (ryzen 1700x, not putting the sleep I can achieve 17K RPS)

Running same code from the laptop yield a max RPS of 30 or less, so maybe there are timeout or mutex somewhere blocking it. (no sleep code lead to 12K RPS)

Cpu usage during the sleep test is practically 0, so there must be some lock and timeout some where I think