Re: [PATCH glibc-2.44] Fix __pthread_timedblock for hurd

Samuel Thibault <[email protected]>
Newsgroups gmane.os.hurd.bugs
Organization I am not organized
Message-ID <aodxjxt-r9VvCs7p@end>
Hello,

Damien Zammit, le mer. 19 août 2026 00:14:46 +0000, a ecrit:
> #3  0x0000000001145061 in __pthread_cond_timedwait_internal (cond=0x40b8348, mutex=<optimized out>, clockid=<optimized out>, abstime=<optimized out>) at ../sysdeps/htl/pt-cond-timedwait.c:164
> #4  0x00000000023b3828 in os::Linux::safe_cond_timedwait (_cond=0x40b8348, _mutex=<optimized out>, _abstime=0x3fc2db0) at /part4/git/icedtea/openjdk-boot/hotspot/src/os/linux/vm/os_linux.cpp:5321
> #5  os::PlatformEvent::park (this=0x40b8300, millis=<optimized out>) at /part4/git/icedtea/openjdk-boot/hotspot/src/os/linux/vm/os_linux.cpp:6040

This uses compute_abstime to produce abst. compute_abstime does really
compute an absolute time, not a relative time, by using either
clock_gettime(CLOCK_MONOTONIC) (if supports_monotonic_clock() returns
true), or gettimeofday() (i.e. CLOCK_REALTIME) otherwise.

So this looks all coherent in using an absolute time. If you have a
hang, you should check that the various values are coherently computed.

Samuel
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.