diff options
| author | Stefan Boberg <[email protected]> | 2023-06-07 13:25:30 +0200 |
|---|---|---|
| committer | Stefan Boberg <[email protected]> | 2023-06-07 13:25:30 +0200 |
| commit | 165d5472afe3c3d13c8c855701c00180507ebe54 (patch) | |
| tree | b32d3f589abd12f487b800632882140e3e4a3538 /src/zenhttp/httpasio.cpp | |
| parent | 0.2.13-pre1 (diff) | |
| download | zen-165d5472afe3c3d13c8c855701c00180507ebe54.tar.xz zen-165d5472afe3c3d13c8c855701c00180507ebe54.zip | |
added thread names to timer, upstream monitor
also altered http-asio thread naming scheme
Diffstat (limited to 'src/zenhttp/httpasio.cpp')
| -rw-r--r-- | src/zenhttp/httpasio.cpp | 11 |
1 files changed, 10 insertions, 1 deletions
diff --git a/src/zenhttp/httpasio.cpp b/src/zenhttp/httpasio.cpp index b76f3d2e3..8ac36c7f3 100644 --- a/src/zenhttp/httpasio.cpp +++ b/src/zenhttp/httpasio.cpp @@ -1250,10 +1250,19 @@ HttpAsioServerImpl::Start(uint16_t Port, int ThreadCount) m_Acceptor.reset(new asio_http::HttpAcceptor(*this, m_IoService, Port)); m_Acceptor->Start(); + // This should consist of a set of minimum threads and grow on demand to + // meet concurrency needs? Right now we end up allocating a large number + // of threads even if we never end up using all of them, which seems + // wasteful. It's also not clear how the demand for concurrency should + // be balanced with the engine side - ideally we'd have some kind of + // global scheduling to prevent one side from preventing the other side + // from making progress. Or at the very least, thread priorities should + // be considered. + for (int i = 0; i < ThreadCount; ++i) { m_ThreadPool.emplace_back([this, Index = i + 1] { - SetCurrentThreadName(fmt::format("asio worker {}", Index)); + SetCurrentThreadName(fmt::format("asio_io_{}", Index)); try { |