Luanti logo

IRC log for #luanti-dev, 2025-08-24

| Channels | #luanti-dev index | Today | | Google Search | Plaintext

All times shown according to UTC.

Time Nick Message
00:23 v-rob joined #luanti-dev
02:45 aliasalreadytake joined #luanti-dev
02:48 fgaz joined #luanti-dev
04:00 MTDiscord joined #luanti-dev
05:11 dv^_^ joined #luanti-dev
05:35 SFENCE joined #luanti-dev
05:55 v-rob joined #luanti-dev
06:20 SFENCE joined #luanti-dev
06:24 YuGiOhJCJ joined #luanti-dev
07:02 SFENCE joined #luanti-dev
07:13 SFENCE joined #luanti-dev
07:14 SFENCE joined #luanti-dev
07:46 whosit Somehow HTTPRequest.timeout does not work against this "server": https://paste.debian.net/hidden/10ded26d/ (but just `curl --max-time` does). CURLOPT_TIMEOUT_MS should be same thing?
07:49 whosit (requests just hang indefinitely like when timeout is not specified)
07:55 whosit testing it with this mod: https://paste.debian.net/hidden/c93bd022/
08:07 cbrpnk joined #luanti-dev
08:19 sfan5 >Pass a long as parameter containing timeout - the maximum time in milliseconds that you allow the libcurl transfer operation to take.
08:20 sfan5 if the transfer never starts, it never times out
08:20 sfan5 Luanti also sets a connect timeout but that's not relevant here either
08:22 Warr1024 joined #luanti-dev
08:30 whosit heh, it does not work with float numbers less than one...
08:31 whosit (the lua API)
08:31 whosit but I'm still confused
08:31 whosit setting timeout = 0.9 makes timeout passed to curl = 0, it seems?
08:34 whosit https://curl.se/libcurl/c/CURLOPT_TIMEOUT.html - "Pass a long as parameter containing timeout - the maximum time in seconds that you allow the entire transfer operation to take. The whole thing, from start to end."
08:34 thelounge65649 joined #luanti-dev
08:34 whosit I would expect HTTPRequest.timeout to be this...
08:36 wsor4035 joined #luanti-dev
08:37 sfan5 it works like this, what's the problem?
08:38 whosit setting HTTPRequest.timeout = 0.9 makes requests hang forever and never time out
08:39 whosit wait... this time it worked...
08:40 sfan5 floats are not allowed
08:40 whosit I guess because python part ran out of number of connections it can accept...
08:40 sfan5 0.9 = 0
08:41 whosit timeout = 10, -- Timeout for request to be completed in seconds. Default depends on engine settings.
08:42 sfan5 okay apparently my theory about non-completed requests does not hold and CURLOPT_TIMEOUT should cover everything
08:43 whosit https://github.com/luanti-org/luanti/blob/master/src/httpfetch.cpp#L258
08:43 whosit luanti even uses CURLOPT_TIMEOUT_MS, which makes it even more confusing...
08:44 whosit (confusing as to why you can't pass timeout<1.0
08:45 sfan5 the api code does the equivalent of timeout = luaL_checkinteger() * 1000
08:45 sfan5 and zero means no timeout
08:46 whosit it's not documented in the lua_api and we're running our mod with timeout = 0.9... which makes it possible for connection pool to be used up unexpectedly
08:46 whosit and permanently
08:47 Warr1024 joined #luanti-dev
08:47 sfan5 well don't do that
08:47 sfan5 PRs to fix the documentation are welcome
08:47 whosit why not assert(timeout > 1) then?
08:47 sfan5 is it wrong to disable timeouts?
08:47 whosit on the lua side, before it get truncated?
08:48 whosit timeout > 1 or timeout == 0 :p
08:49 whosit could argue that having timeout disabled is wrong if the pool can get filled with stuck connections with no way to remove them
09:00 whosit I'm poking at this because we have main thread freezing for 2 minutes, and main suspect is the http.fetch() call - still no idea what happens exactly
09:01 whosit (unless profiler is lying)
09:39 m42uko joined #luanti-dev
11:01 Farooq joined #luanti-dev
11:37 Dragoni joined #luanti-dev
11:37 wsor4035 joined #luanti-dev

| Channels | #luanti-dev index | Today | | Google Search | Plaintext