On 30.10.2023 22:09, Martin Storsjö wrote:
On Mon, 30 Oct 2023, Jacek Caban wrote:
GetTickCount64 is used only for _pthread_wait_for_*_objects wrappers,
where the timeout is 32-bit anyway, so it should be possible to use
GetTickCount unconditionally and avoid the whole problem. It would
need a bit of overflow handling, but nothing too bad.
However, looking at _pthread_wait_for_*_objects helpers, I'd argue
that they don't make sense in the first. The comment claims that
system functions have poor accuracy and then uses a function with the
same accuracy to check that and unnecessary delay wait... I'd say we
could just revert 52f2ce12c6182bd239e4f1bbffcd420997b64b08.
Thanks for having a look at this level.
However, I can kinda see the argument against returning too early
though, so I could see that it makes sense to wrap WaitFor*Object(s)
in a loop - do you agree with that?
I find the claim that it's fine to wait for longer to be questionable.
GetTickCount's value may be off by up to 16 ms, so the way elapsed time
is calculated in those helpers may be off by up to 32 ms. I guess that
precise waits matter mostly for short timeouts in scenarios where
timeouts are semi-expected to happen and then the overhead of
over-waiting may be not negligible. I wonder if the observed too short
waits are an effect of measurements problems in tests, but I can't judge
on that without seeing tests. All operating systems will have some sort
of accuracy considerations in this area and kernel is in a better
position to handle it than we are.
Anyway, I realize that a revert to be controversial and don't intend to
insist. Playing with plain GetTickCount is probably worth a try, through.
Jacek
_______________________________________________
Mingw-w64-public mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
