[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20261107221247.GI23438@brightrain.aerifal.cx>
Date: Sat, 7 Nov 2026 17:12:47 -0500
From: Rich Felker <dalias@...c.org>
To: Luca Kellermann <mailto.luca.kellermann@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: [PATCH] thrd_create: inherit signal mask from creating
thread
On Sat, Nov 07, 2026 at 10:51:27PM +0100, Luca Kellermann wrote:
> On Thu, Nov 05, 2026 at 01:54:13PM -0500, Rich Felker wrote:
> > On Thu, Nov 05, 2026 at 03:39:51PM +0100, Luca Kellermann wrote:
> > > POSIX.1-2024 requires that the new thread created by thrd_create()
> > > inherits the signal mask from the creating thread, just like the new
> > > thread created by pthread_create().
> > >
> > > it seems like this was initially the case when thrd_create() was
> > > implemented in commit 23614b0fcb4cd4d7b2e4148d3b1887b642169765. commit
> > > 04335d9260c076cf4d9264bd93dd3b06c237a639 then changed pthread_create()
> > > to always block signals before starting new threads but restoring the
> > > signal mask was only done for new threads started by pthread_create()
> > > (start()), not for new threads started by thrd_create() (start_c11()).
> > > this was before POSIX included threads.h, so it didn't violate any
> > > specification back then (the C standard doesn't know signal masks).
> >
> > Hm, I thought this was intentional. Threads created by library code to
> > be transparent to the calling application need to be created with all
> > signals masked. Since ISO C has no way to mask signals, the
> > thrd_create interface should just do that itself.
>
> At least nothing in the commit message indicates it was intentional.
> But I agree that blocking all signals is better.
Yeah, that's why I said thought. My recollection was that it was
intentional, but I didn't see any evidence to that effect when I
looked.
Any change to this it will be part of a process of lots of updates to
align with POSIX 2024, so there's some time to figure out what to do.
> > If POSIX now requires them to inherit, we should probably change that,
> > but it might be worth opening a defect report. Inheriting signal mask
> > was really a bug in pthreads, and imposing the same on C11 threads
> > where the library code creating the may be POSIX-unaware seems like a
> > bad thing.
>
> How do you open a defect report?
On the tracker at https://austingroupbugs.net
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.
