uWS::Loop standalone usage

[markmaker]

Hi,

I'm trying to use a uWS::Loop standalone, i.e., without an uWS::App, in one or more separate threads, so I can loop->defer() CPU-bound and/or synchronous tasks to it, exactly the same way that task then defers the response back to the central uWS::App loop (res->send(), res->end() or ws->send() inside the defer). A nice symmetric system. 😄

After some tweaking, this works nicely, performant, and very robustly even when hammered, but I still have two questions:

1. Calling the standalone loop->run() immediately falls through, as just waiting for deferred work does not count as "active". Is there a way to make such a standalone loop remain active?
   Note, just because I'm using libuv (LIBUS_USE_LIBUV), I was able to fix this by adding my own active libuv handles to the underlying native uv loop, but that would not work with plain uWS, so I'm wondering if there is an official way.
2. Once I got the standalone loop running, I noticed there is a 1-second interval timer installed (my uv_prepare_t gets called once a second). Can I somehow get rid of it, or stop it, or at least set a longer interval? Why is it there?

Thanks,
_Mark

[uNetworkingAB]

Why don't you use a proper thread pool? It's simpler and faster

[markmaker]

Because in that other thread, I want to use asynchronous techniques too, i.e., I need to handle events other than queued tasks (signal handlers, timers, idle handlers, etc.). Therefore, some kind of loop is a must, and I just thought it would be nice and symmetrical to use the same loop tech.

Furthermore, libuv's uv_async_t sucks in that it does not queue. Your defer does. Plus you implement MoveOnlyFunction (not that I understand it, or its implications fully yet). 😅

It also happens that I want to use the main thread as the worker. Most thread pools can't do that. Yes, it's a legacy single threaded data-base-centric, forked app that must run tasks of a user-session in tight serialized ACID transactions.

Finally, it's one dependency less. 😌

[uNetworkingAB]

I don't know what the 1 second timer is, we don't have such a timer. We have a 4 second timer but only if you have an App running.

[markmaker]

I had a look, I guess it's the uWS::Loop::dateTimer instantiated in uWS::Loop::create:

uWebSockets/src/Loop.h

Lines 76 to 87 in fc2b7be

	static Loop *create(void *hint) {
	Loop *loop = ((Loop *) us_create_loop(hint, wakeupCb, preCb, postCb, sizeof(LoopData)))->init();
	/* We also need some timers (should live off the one 4 second timer rather) */
	LoopData *loopData = (LoopData *) us_loop_ext((struct us_loop_t *) loop);
	loopData->dateTimer = us_create_timer((struct us_loop_t *) loop, 1, sizeof(LoopData *));
	memcpy(us_timer_ext(loopData->dateTimer), &loopData, sizeof(LoopData *));
	us_timer_set(loopData->dateTimer, [](struct us_timer_t *t) {
	LoopData *loopData;
	memcpy(&loopData, us_timer_ext(t), sizeof(LoopData *));
	loopData->updateDate();
	}, 1000, 1000);

Creates a HTTP date stamp. Is referenced here:

uWebSockets/src/HttpResponse.h

Line 79 in fc2b7be

writeHeader("Date", std::string_view(((LoopData *) us_loop_ext(us_socket_context_loop(SSL, (us_socket_context(SSL, (us_socket_t *) this)))))->date, 29));

Surely saves some processing time in a heavy loaded server, but could perhaps be moved from uWS::Loop to uWS::App.

[uNetworkingAB]

Ok, all apps on the same Loop have the same Date so that's why it is on the Loop. Forgot about that one

[markmaker]

Does make sense. Thanks.