Hi Paul,
I noticed that when updating the docs for POSIX 2024 you improved the
documentation for removals from POSIX [1]. Like this:
diff --git a/doc/pastposix-functions/bcmp.texi
b/doc/pastposix-functions/bcmp.texi
index 13906aabd2..00ef702a7a 100644
--- a/doc/pastposix-functions/bcmp.texi
+++
Bruno Haible writes:
> Hope you can debug it. I can't — when I give 8 CPUs to my NetBSD VM,
> I can't log in to the console any more because every keystroke is repeated
> 3 or 4 times.
I'll try to come up with a fix sometime tomorrow or this weekend. Upon
first glace I see that NetBSD uses the f
Collin Funk wrote:
> $ time ./gltests/test-pthread-once2
> Starting test_once ... OK
>
> real 8m6.167s
> user 56m55.342s
> sys 7m44.460s
>
> $ time ./gltests/test-call_once2
> Starting test_once ...Alarm clock
>
> real 10m4.626s
> user 71m5.161s
> sys 9m31.302s
So, there is definitely a
Collin Funk writes:
>> Then, you might see whether setting ENABLE_DEBUGGING to 1 in the test's
>> code reveals a pattern...
>
> Thanks for the advice. I'll do some experimenting and let you know what
> I find.
>> $ time ./test-pthread-once1
$ time ./gltests/test-pthread-once1
real0m0.00
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
>
> real 10m0.002s
> user 90m18.341s
> sys 9m38.634s
Indeed, that's 5 times slower...
> Alternatively we could work ar
> So, in summary, it's a glibc bug that has been closed as "WORKSFORME" and
> will never be fixed [3].
>
> In the test-pthread-rwlock test, we cannot just use
> PTHREAD_RWLOCK_WRITER_NONRECURSIVE_INITIALIZER_NP, because the *purpose* of
> the test is to check the behaviour of the rwlocks with the
On 6/27/24 15:46, Bruno Haible wrote:
The laptop uses an Intel Core i5-1335U.
So, 'cat /proc/cpuinfo' shows 12 CPUs, right?
Right.
The process had many threads active.
It should use 11 threads. You didn't see 100 threads, right?
Right.
gnulib-tool already has an option --with-longru
Bruno Haible writes:
> Collin Funk wrote:
>> I created the virtual machine with 8 cores and 8 GB memory.
>
> Ah, this explains why I never saw this: I create most of my VMs with 1 CPU
> (so that I can run a dozen of them in parallel).
Haha. I use a different strategy I guess. One virtual machine
Collin Funk wrote:
> > * tell how many threads your machine supports?
>
> I created the virtual machine with 8 cores and 8 GB memory.
Ah, this explains why I never saw this: I create most of my VMs with 1 CPU
(so that I can run a dozen of them in parallel).
> > test-pthread-mutex
>
> $ time .
Bruno Haible writes:
> Can you please
> * measure the execution time of each of the locking tests?
Sure. Let me know if there is any other tests you need run.
> test-pthread-mutex
$ time ./gltests/test-pthread-mutex
Starting test_pthread_mutex_normal ... OK
Starting test_pthread_mutex_recurs
* lib/strftime.c: Include locale.h unconditionally, simplifying
the code. Emacs is now open for this change, which we had wanted
to do earlier.
---
ChangeLog | 7 +++
lib/strftime.c | 7 +--
2 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/ChangeLog b/ChangeLog
index f0
Collin Funk wrote:
> It was one of the locking tests but I forget if it was test-pthread-rwlock.
Can you please
* measure the execution time of each of the locking tests?
test-pthread-mutex
test-pthread-rwlock
test-lock
test-rwlock1
test-mtx
* tell how many threads your machine supports?
Hi Paul,
I wrote:
> > The process had many threads active.
>
> It should use 11 threads. You didn't see 100 threads, right?
Looking at the test's code, it should use 21 threads.
1) I measured the execution time of this test, on various distributions,
with various kernels, and various numbers o
Hi Bruno,
Bruno Haible writes:
>> Does anyone know why
>> RFC 2553 has the larger buffer size? I thought per RFC 1034 domain names
>> were limited to 253 bytes, with the trailing dot removed and empty root
>> label removed [3].
>
> I think [1] explains it:
> "The first value is actually define
Hi Bruno,
Bruno Haible writes:
> Interesting. On my system — also 2.35-0ubuntu3.8 — the test completes
> in ca. 7 seconds each time.
>
> I'll try to reproduce and investigate.
If it helps you investigate I think I ran into a similar issue when
building findutils on a NetBSD 10.0 virtual machine
Tim Rice wrote:
> This was more for reference than asking to add for support for OpenServer 5.
OK.
> > sense, since SCO OpenServer 5 is a museum system, as you can see
>
> True, old.
Glad you acknowledge that.
> Just please do not remove any bits related to OpenServer 5 until
> Xinuos announce
Hi Paul,
> When running './gnulib-tool --test nstrftime" on my laptop's Pop!_OS
> 22.04 LTS, test-pthread-rwlock went into what appeared to be a CPU bound
> infinite loop. It would have drained the battery if I hadn't been
> plugged into the wall. The process had many threads active. I eventual
When running './gnulib-tool --test nstrftime" on my laptop's Pop!_OS
22.04 LTS, test-pthread-rwlock went into what appeared to be a CPU bound
infinite loop. It would have drained the battery if I hadn't been
plugged into the wall. The process had many threads active. I eventually
gave up and ki
Hi Collin,
> #define NI_MAXHOST 1025
> #define NI_MAXSERV32
>
> That is what glibc does too. I've applied the attached patches to make
> sure these are defined correctly.
Thanks. After reading [1] and [2], I agree that's the right thing to do.
> Does anyone know why
> RFC 2553 has
After Bruno mentioned the IPv4 limitation on inet_ntoa I decided to look
at modernizing Inetutils again. I also noticed gethostbyname,
gethostbyaddr were used which were obsoleted in POSIX 2001 and removed
in POSIX 2008.
Not too difficult to change to getaddrinfo and getnameinfo, but it means
choo
20 matches
Mail list logo
