on Fri, 26 May 2023 13:50:57 -0700 you (Hans Boehm <boehm_at_[hidden]>)
wrote:

> On Fri, May 26, 2023 at 1:10 PM Jₑₙₛ Gustedt <jens.gustedt_at_[hidden]>
> wrote:

> > More directly from the text follows that calling that `signal` in an
> > execution that has (had) multiple threads, is a fault. This was
> > what I was first thinking, too, but it may be more subtle than that,
> > actually. It is undefined what concerns the C standard, but it also
> > means that other standards such as POSIX may prescribe some specific
> > behavior here.
> >
> Posix doesn't have that restriction, though I think its wording is
> otherwise a bit obsolete.

That may be exactly the point. POSIX allows the use here. If C would
prescribe a fault, POSIX systems would not be conforming to C.

> I read the wording here as also prohibiting signal() if we later fork
> a second
> thread, with the motivation of dodging issues about where the handler
> runs. That would mean that "safe" visible side-effects would need to
> happen before the later of the signal() call and the initial thread
> creation.
>
> It would be good to clarify what was actually intended.

My guess is that there were quite varying implementations of signals
(and `signal` in particular) arround such that WG14 didn't wanted to
prescribe any behavior that these systems might have. (Or maybe was
just not able to find a consensus?)

Thanks
Jₑₙₛ

-- 
:: ICube :::::::::::::::::::::::::::::: deputy director ::
:: Université de Strasbourg :::::::::::::::::::::: ICPS ::
:: INRIA Nancy Grand Est :::::::::::::::::::::::: Camus ::
:: :::::::::::::::::::::::::::::::::::: ☎ +33 368854536 ::
:: https://icube-icps.unistra.fr/index.php/Jens_Gustedt ::