[PATCH] doc: Mention the byteswap module in function documentation.

* doc/glibc-functions/bswap_16.texi (bswap_16): Mention the byteswap module. * doc/glibc-functions/bswap_32.texi (bswap_32): Likewise. * doc/glibc-functions/bswap_64.texi (bswap_64): Likewise. --- ChangeLog | 8 doc/glibc-functions/bswap_16.texi | 2 +- doc/glibc-f

Re: a pthread_cond_timedwait bug

Hi Bruno, Bruno Haible writes: > The suspicion thus moved to the hypervisor. I tried a couple of VMs under > QEMU (with '-smp 8' for 8 CPUs, and on x86_64 with '-enable-kvm'), and > there the test succeeds. Unrelated to the test, but you might like 'virt-manager' for setting up KVM virtual mach

Re: test-pthread-rwlock failure on Pop!_OS 22.04 LTS

Hi Paul, These measurements: > * in virtual machines with 8 CPUs: > > - Ubuntu 22.0460 sec (4 CPUs: 15 sec) > > * outside VirtualBox: > > - Ubuntu 22.04 (12 CPUs) 6 sec together with the investigation of the pthread_cond_timedwait "bug", makes it sound possible

Re: [PATCH] tests: switch nap() to use file creation to gauge delay

Jeff Layton wrote: > Failure of the test-stat-time test is what triggered us to revert the > multigrain timestamp series from the Linux kernel last October. With > that failure, we'd sometimes see timestamps showing files being modified > in reverse order (if one got a fine-grained and another got

Re: a pthread_cond_timedwait bug

I wrote: > Even though the futex was supposed to time out at 1719588805.808799 > it terminated only at 1719588806.863658 > which is more than 1 second too late. > > It seems that this is the same bug as > . Wrong

[PATCH] tests: switch nap() to use file creation to gauge delay

The current test in nap.h tries to gauge the minimum delay that results in a timestamp change when successively writing to a file. There are some proposed changes [1] to track finer-grained timestamps in the Linux kernel that will break the assumptions that nap() uses to gauge the delay. In partic

a pthread_cond_timedwait bug

While testing a 'pthread-rwlock' testdir on various VMs with 8 CPUs, there was also a failure of 'test-pthread-cond' on Debian 10. It's reproducible: On that Debian 10.7 VM (glibc 2.28, Linux 4.19.0) with 8 CPUs, 'test-pthread-cond' with a probability of ca. 20%..30% aborts. Stack trace: test-pt

Re: test-pthread-rwlock failure on Pop!_OS 22.04 LTS

Some more measurements in virtual machines with 8 CPUs: Debian 9 (glibc 2.24) 4 CPUs: 0.33 sec 8 CPUs: 0.34 sec Debian 10 (glibc 2.28) 4 CPUs: 23 sec8 CPUs: 29 sec So, while glibc < 2.25 did not prefer writers (like musl libc, OpenBSD 7.5, AIX), it's only starting with

Re: test-pthread-rwlock failure on Pop!_OS 22.04 LTS

I wrote: > 3) This topic has been discussed in the glibc bug > https://sourceware.org/bugzilla/show_bug.cgi?id=13701 > where I have raised my voice for a writer-preferring implementation. The rwlock implementation being not writer-preferring appears to be only one contributing factor. I did "time

Re: doc: Improve documentation of previous POSIX functions.

Bruno Haible writes: >> Are POSIX functions always removed the following release that they are >> marked obsolete? > > I would not make such an assumption. But the changes you made are OK; > I cross-checked by looking at the section "CONFORMING TO" of the > corresponding Linux man-pages. Thats w

Re: test-pthread-rwlock failure on Pop!_OS 22.04 LTS

On 6/28/24 01:44, Bruno Haible wrote: Paul Eggert wrote: On my Pop_OS! laptop it's way slower than it was on any of your measured VMs: $ time ./test-pthread-rwlock Starting test_rwlock ...Alarm clock real10m0.002s user90m18.341s sys 9m38.634s Indeed, that's 5 times slower... It

time: Fix test failure on FreeBSD

The test-time test fails on FreeBSD 14.0/x86_64, in a VirtualBox VM, but only if 2 or more CPUs are assigned to the VM. This patch fixes it. 2024-06-28 Bruno Haible time: Fix test failure on FreeBSD. * m4/time.m4 (gl_FUNC_TIME): Guess no for FreeBSD in general. * doc/

Re: doc: Improve documentation of previous POSIX functions.

On 6/28/24 04:31, Collin Funk wrote: Are POSIX functions always removed the following release that they are marked obsolete? Typically, but no guarantee.

Re: doc: Improve documentation of previous POSIX functions.

Collin Funk wrote: > I've committed this patch doing the same for the rest of the files in > doc/pastposix-functions/*.texi since I think it is helpful. Thanks. > Are POSIX functions always removed the following release that they are > marked obsolete? I would not make such an assumption. But th