Make select_read timeout configurable

[nioncode]

I'm using httplib during tests of a client application in order to verify the requests that are made, which works great so far (thanks!).

However, I'm running into a performance problem: for each test case, I'm creating a new Server, listen for requests (on a separate thread), and stop the server (and join the thread) after the test finished. The problem is that the listen call only returns after ~100ms, which is caused by the 100000 usec timeout of select_read (inside the listen_internal method). If I change this timeout to 0, my tests finish in 5ms instead of 105ms (multiplied by the number of test cases, which quickly adds up).

It would be great if we could configure the timeout or completely disable the select call. Maybe it even makes sense to set this value to 0 automatically when the stop method is called? I don't know much about the effects of this, but from my understanding, when I ask the server to stop, it should stop as fast as possible and not wait for some timeouts on sockets.

[yhirose]

@nioncode, thanks for the feedback. I don't have any particular reason why I have set the timeout to 100000, and it seems like there is no problem with 0. I'll commit the change after I make sure that all the unit test pass. Thanks for your contribution!

[nioncode]

Thanks for the very fast response.

Why is select_read actually used in this loop anyways? Shouldn't the accept be enough? It looks like the task_queue->on_idle() is not even used, since on_idle() is an empty method.

With the code being as it is now, I would assume that a timeout on the select is generally preferred in order to keep CPU usage lower during idle, as otherwise the loop would basically loop busy without sleeps (since the select timeout is removed) now, since the select always times out if there is no request coming in. This should result in a high CPU usage compared to the previous state, so I think it is not a good idea to simply remove the timeout here completely in all use cases (I'm totally fine with that for my test purposes, but I'd assume that in a real server scenario, the timeout is needed or the select should be dropped completely and only use accept).

[yhirose]

@nioncode, thanks for your comment. You are right. I looked back at some commits related to this. It turns out that it was originally added to handle the keep-alive connection and to detect that the server socket is closed: 23c8f0c

The current code actually doesn't need it any more for this purpose. But it's now used to call on_idle() method on a task queue object periodically, so that the task queue can be configured according to current situation. (The build-in default task queue in cpp-httlib does nothing as you have already noticed.) This feature was implemented based on the issue #442.

Anyway, I'll find a way to handle both requirements properly. Thanks for your fine insight!

[nioncode]

The easiest would probably be to just make the timeout adjustable through the constructor (a #define would actually also work in my case, but I don't really like using the pre-processor for such things), but I'm looking forward to your solution.

[yhirose]

I fixed this issue again in the way that's different from previous. I added set_idle_interval(sec, usec) method on the Server class. If we set 0, the server will completely skip the idle event process. The default value is 100000, and it can be configurable at compile time as well.
Hope the fix goes well for you.

cpp-httplib/httplib.h

Line 529 in 62e036f

void set_idle_interval(time_t sec, time_t usec);

cpp-httplib/httplib.h

Lines 3976 to 3986 in 62e036f

	while (svr_sock_ != INVALID_SOCKET) {
	if (idle_interval_sec_ > 0 || idle_interval_usec_ > 0) {
	auto val = detail::select_read(svr_sock_, idle_interval_sec_,
	idle_interval_usec_);
	if (val == 0) { // Timeout
	task_queue->on_idle();
	continue;
	}
	}
	socket_t sock = accept(svr_sock_, nullptr, nullptr);

[yhirose]

After I thought more about the default value for CPPHTTPLIB_IDLE_INTERVAL_USECOND. Since most users don't need the idle event, I changed it to 0. So in your case, you don't have to do anything. Hope it helps.

cpp-httplib/httplib.h

Lines 43 to 49 in 0654e5d

	#ifndef CPPHTTPLIB_IDLE_INTERVAL_SECOND
	#define CPPHTTPLIB_IDLE_INTERVAL_SECOND 0
	#endif
	#ifndef CPPHTTPLIB_IDLE_INTERVAL_USECOND
	#define CPPHTTPLIB_IDLE_INTERVAL_USECOND 0
	#endif

[yhirose]

After I set both CPPHTTPLIB_IDLE_INTERVAL_SECOND and CPPHTTPLIB_IDLE_INTERVAL_USECOND to 0, one of unit tests no longer works on Windows...

I'll continue to find a solution for any situation.

[yhirose]

It turns out the select_read check is need for Winsock to properly stop the loop by calling stop() in a different thread. Other OSs like linux and macOS don't have the problem.

https://stackoverflow.com/questions/8716464/unblock-a-blocked-winsock-accept-call#answer-8720202

The current version v0.6.5 should work on all the OSs.

[nioncode]

Just wanted to report back that I tested again with v0.6.5 and everything works fine, thank you.

However, I'm curious about the Windows problem that you mentioned and especially about your solution. The link you posted even says it should be enough to simply close the socket from another thread (which httplib does when stop gets called). However, I can confirm from my tests that the select is indeed needed on windows, since it seems the accept does not unblock otherwise, which seems to contradict the answers in the SO question you linked. Am I missing something?