[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Fri, 2 Aug 2019 23:46:25 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] Add gettid and tgkill syscall wrappers.
* Rich Felker <dalias@...c.org> [2019-08-02 16:25:16 -0400]:
> On Thu, Aug 01, 2019 at 04:31:11PM -0400, James Y Knight wrote:
> > +++ b/src/linux/tgkill.c
> > @@ -0,0 +1,8 @@
> > +#define _GNU_SOURCE
> > +#include <signal.h>
> > +#include "syscall.h"
> > +
> > +int tgkill(pid_t pid, pid_t tid, int sig)
> > +{
> > + return syscall(SYS_tgkill, pid, tid, sig);
> > +}
> > --
> > 2.22.0.770.g0f2c4a37fd-goog
>
> Is pid_t the right type for this? Fundamentally the futex interface
> imposes a requirement that tids fit in 29 bits of int. pid_t *is* int
> anyway, but it's more a matter of figuring out what the right semantic
> type for this is.
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/bits/signal_ext.h
> I also question whether tgkill should be a supported API. The idea of
> being able to address threads of other processes is dubious. Before we
> start adding these, I think we should think about which ones make
> sense as APIs that applications can safely use.
i think the idea is that there will be thin wrappers for linux syscalls
even if they may be misused.
> Also, pthread_gettid_np or something like that is probably important
> to being able to use any interfaces involving tids; otherwise you can
> only address yourself without explicit communication with a thread to
> query its tid.
i dont think glibc has such api now.
> Is there a list of which interfaces glibc will be adding and their
> rationale?
not that i know of, the apis are added one by one with separate reviews.
https://sourceware.org/glibc/wiki/Consensus#WIP:_Kernel_syscalls_wrappers
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
