AFAIK calling signal() in a threaded process is undefined behaviour.
I think I could sleep better at night if this was changed to implementation
defined.

The reason is, that as far as I understand this, all signal() calls
should be completed before starting any additional threads. I am
violating this principle frequently. E.g. when a linked library starts
a thread even before main() is called. Also I am using the following
construct for registering signals:

using sig_t =3D void (*)(int);
class Signal {
 private:
 int const sig;
 sig_t const handler;

 public:
 Signal(int const sig, sig_t const handler) :
 =C2=A0=C2=A0=C2=A0=C2=A0sig{sig}, handler{::signal(sig, handler)} {
  if (this->handler =3D=3D SIG_ERR) {
   throw sc_error<error>{errno};
  }
 }

 ~Signal() {
  ::signal(this->sig, this->handler);
 }
};

So I use this RAII wrapper to make signal handling contextual and
stackable, because a Signal instance restores the previous handler
when going out of scope.

In practice the operating systems I use make firm guarantees about
what happens with signals in a threaded context. The underlying
sigaction calls allows blocking signals on a per-thread basis at le'ast
on FreeBSD, so it's possible to implement a thread local version of
signal. I assume the situation is similar.

Making the behaviour implementation defined would work for me, but
what I think the standard *should* guarantee is:

- The initial default handlers of a process are only executed in the
=C2=A0 main thread.
- New threads have all signals blocked (this implies the previous rule).
- Signals are registered for the thread with the signal() call only.

This means every signal handler is only called as often as it has been
registered through a signal() call, but different threads can react to
the same signal. The latter is useful for libraries, i.e. consider a
GUI lib that manages resources, like windows, canvasses etc.https://github.=
com/lonkamikaze/powerdxx/issues/3.

Regards

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?


--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1483704209.74009.24.camel%40bsdforen.de.

.

Please ignore weird hand on the trackpad, accidental paste glitches.

I am sorry for the inconvenience.

At least one of them happened after proofreading.

--
A: Because it fouls the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?


--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/1483704894.74009.27.camel%40bsdforen.de.

.

--001a11400c0476757905456c0404
Content-Type: text/plain; charset=UTF-8

On Fri, Jan 6, 2017 at 1:03 PM, Dominic Fandrey <kamikaze@bsdforen.de>
wrote:

> AFAIK calling signal() in a threaded process is undefined behaviour.

I do not think this is correct. The standard merely states that it is
unspecified in which thread thread the handler will execute. See clause
1.10.2 in C++'14.

Cheers,
V.

--
You received this message because you are subscribed to the Google Groups "ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an email to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2bWW9fbWQLLF4q-WatHLMBG0Q4-hoJrR-H-8qD8VOLgQ%40mail.gmail.com.

--001a11400c0476757905456c0404
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On F=
ri, Jan 6, 2017 at 1:03 PM, Dominic Fandrey <span dir=3D"ltr">&lt;<a href=
=3D"mailto:kamikaze@bsdforen.de" target=3D"_blank">kamikaze@bsdforen.de</a>=
&gt;</span> wrote:</div><div class=3D"gmail_quote"><br></div><div class=3D"=
gmail_quote">&gt; AFAIK calling signal() in a threaded process is undefined=
 behaviour.<div><br></div><div>I do not think this is correct. The standard=
 merely states that it is unspecified in which thread thread the handler wi=
ll execute. See clause 1.10.2 in C++&#39;14.</div><div><br></div><div>Cheer=
s,</div><div>V.</div><div><br></div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;ISO C++ Standard - Future Proposals&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:std-proposals+unsubscribe@isocpp.org">std-proposa=
ls+unsubscribe@isocpp.org</a>.<br />
To post to this group, send email to <a href=3D"mailto:std-proposals@isocpp=
..org">std-proposals@isocpp.org</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2bWW9fbWQLLF4q-WatHLMBG0Q4-hoJ=
rR-H-8qD8VOLgQ%40mail.gmail.com?utm_medium=3Demail&utm_source=3Dfooter">htt=
ps://groups.google.com/a/isocpp.org/d/msgid/std-proposals/CAA7YVg2bWW9fbWQL=
LF4q-WatHLMBG0Q4-hoJrR-H-8qD8VOLgQ%40mail.gmail.com</a>.<br />

--001a11400c0476757905456c0404--

.

Em sexta-feira, 6 de janeiro de 2017, =C3=A0s 13:18:36 PST, Viacheslav Usov=
=20
escreveu:
> On Fri, Jan 6, 2017 at 1:03 PM, Dominic Fandrey <kamikaze@bsdforen.de>
>=20
> wrote:
> > AFAIK calling signal() in a threaded process is undefined behaviour.
>=20
> I do not think this is correct. The standard merely states that it is
> unspecified in which thread thread the handler will execute. See clause
> 1.10.2 in C++'14.

POSIX has some constraints dealing with threads and signals too. Even if C =
and=20
C++ change their meaning, you still have POSIX standing in the way.

--=20
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center

--=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
To view this discussion on the web visit https://groups.google.com/a/isocpp=
..org/d/msgid/std-proposals/1499071.shlOhSX5Sl%40tjmaciei-mobl1.

.