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 |