mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Markus Wichmann <nullplan@gmx.net>
To: musl@lists.openwall.com
Subject: [musl] pthread_getcpuclockid and POSIX
Date: Tue, 8 Oct 2024 17:26:22 +0200	[thread overview]
Message-ID: <ZwVPHvxufLMVs0WR@voyager> (raw)

Hi all,

I am already sorry in advance that this is hardly going to contain
constructive criticism, because at this point, I see a few problems and
no real solutions.

pthread_getcpuclockid() is a function that is supposed to return a
clockid that can be passed to the clock_* and timer_* functions and
references the CPU time of the thread identified by its handle.
Currently, we simply return an encoding of the raw kernel TID. This
means the clockid becomes invalid as soon as the thread terminates.

Minor gripe: Isn't reading the TID from another thread's descriptor
without holding the killlock a potential data race?

Major gripe: If called on a zombie thread, this successfully returns a
clockid that is equivalent to CLOCK_THREAD_CPUTIME_ID. glibc returns
ESRCH in that case, which POSIX neither condones nor condemns. It says
in an informative section that that should be returned for thread
handles used after the end of life of a thread, but the definitions
section in XSH explicitly includes the zombie phase in the thread
lifetime.

POSIX doesn't really say how long such a clockid should be valid, but I
should think the life of the thread at least, and again, that includes
the zombie phase. But our current implementation doesn't deliver that.
If the clockid is retrieved after a thread becomes a zombie, then we
return a valid clockid that doesn't do what the caller thinks it does,
and if called before that, we return a clockid that might not work when
used (if the thread exited between the calls to pthread_getcpuclockid()
and clock_gettime()) or, worse, might refer to a completely different
thread (if a new thread with the same TID was created).

What can be done? If we could somehow encode the thread descriptor into
the clock ID, then clock_gettime() could recognize those CPU times and
do some special handling. For example, it could take the killlock on the
thread and then perform the syscall only if the thread is still alive.
pthread_exit() could store the final CPU time in the thread descriptor
at the same time as it is clearing out the TID, and clock_gettime()
could return that if the thread is no longer alive. Of course, all the
other clock_* and timer_* functions would have to change as well.

Alas, this can probably not be done, as clockid_t is defined to be an
int, and we cannot define it to be larger without breaking ABI.
Shoveling 64 pounds of stuff into a 32-pound bag has never worked
before, so I don't think we can represent a pthread_t in a clockid_t.
Let alone doing so in a way that preserves the static clocks already in
use (and compiled into binary programs), and the dynamic process CPU
time clocks clock_getcpuclockid() returns.

I also struggle to find any users of this interface that aren't always
calling it with the first argument set to pthread_self(). I did find
OpenJDK, which calls it on its main thread. But otherwise, nothing.

Ciao,
Markus

             reply	other threads:[~2024-10-08 15:26 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-10-08 15:26 Markus Wichmann [this message]
2024-10-09 17:31 ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ZwVPHvxufLMVs0WR@voyager \
    --to=nullplan@gmx.net \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).