Time  Nick       Message
18:08 Krock      Not a blocking receive IIRC, but the server only processes very few data per step
19:06 Krock      sfan5: any chance to make use of std::chrono in semaphore.cpp? That time calculation looks awful and attractive for bugs
19:07 sfan5      not really since you need it in a struct timespec in the end
19:11 Krock      I just hope that time calculation is correct
19:14 Krock      okay. looks correct
19:16 sfan5      merging #9115 in a few minutes
19:16 ShadowBot  https://github.com/minetest/minetest/issues/9115 -- Optimize semaphore wait with zero timeout on POSIX by sfan5
19:17 Krock      > Note that this function can potentially wait infinitely
19:18 Krock      Does it? Semaphore in "m_signal.wait" (container.h) should actually prevent that
19:18 sfan5      it does continue on certain events
19:19 Krock      right. added and removed peers
19:20 Krock      No, that's not a problem for now
19:26 Krock      ... the local server runs at some weird non-linear speed (steps). anoying
19:38 Krock      sfan5: "immediately available". Are these packets already cached and ready to process?
19:41 sfan5      yes
19:41 sfan5      it's the packets that are already inside the m_event_queue
19:41 Krock      ah right. filled by ConnectionReceiveThread::receive()
19:44 Krock      nice work
19:49 sfan5      now the issue reporter just needs to say that this fixes the issue
19:51 sfan5      thanks for reviewing
19:54 sfan5      re dtime accuracy: what about making dedicated_server_loop increment dtime more often, but having AsyncRunStep() only do something when `m_step_dtime> dedicated_server_step`?
19:56 Krock      np. these were straight forward rather easy fixes
19:58 Krock      well, that would also be an option. I didn't want to rely more than necessary on delta time values. Sleep is not always so accurate after all
20:02 Krock      and currently the function mostly just returns instantly due to "if((dtime < 0.001) && !initial_step)"
20:02 Krock      caused by setting m_step_dtime to zero each step
20:04 Krock      rather than "m_step_dtime -= dtime;" it would mean "m_step_dtime -= fixed_server_step"
20:04 sfan5      well then dtime would be exactly the fixed step again
20:05 Krock      yes, in any case. regardless how much time actually has passed. until AsyncRunStep is called again, m_step_dtime might already be incremented twice by dedicated_server_step
20:10 Krock      after all it comes down that it's inaccurate by +/- 1 server step. two steps which take 10ms might be run instantly after each other if there's a m_step_dtime increment after 1..9ms
20:10 Krock      given that a previous step took longer than usual
20:44 kilbith    it's good to be sfan5
20:44 kilbith    your PRs only opened for a few hours
20:45 kilbith    if only it was like that for everything else ...
20:45 sfan5      that's also due to the size of my PRs
20:45 sfan5      but yes, there is an obvious advantage if the PR submitter is a coredev
20:45 kilbith    like the CSM PR
20:46 kilbith    caring more of your own PRs yes
20:52 rubenwardy that was also a fix to a fairly critical bug
20:53 rubenwardy wait, different PR
20:53 sfan5      you're not wrong
20:54 sfan5      well not really "critical", but some CSM things were badly broken too
20:57 kilbith    the other ppl fixes are obvously dubious yeah
20:57 kilbith    /s