[Interest] proper (silent) exit in response to SIGHUP - and signal/slot serialisation?

[Thiago Macieira]

On Friday, 19 October 2018 01:39:46 PDT René J.V. Bertin wrote:
> Does Qt serialise slot calling, iow, will it queue signals emitted and
> deliver newer ones only when the previous slot invocation completed?
> 
> Qt::QueuedConnection does kind of suggest it might, which begs the question
> if there's a way around that in this situation?

Like Jason said, "queued" connection implies it's inserted into a queue: the 
event loop's pending event queue. One element is popped off that queue every 
loop cycle and handled, until there are no more events pending. 

Handling another event before the previous has finished is possible. That's 
called event loop nesting. And you also know how that is frowned upon.

It's also possible to insert events with higher priority, but whether it gets 
handled before the event that was supposed to run next or not is 
implementation-defined[*]. The priority feature interferes with the live-lock 
prevention feature, so an event loop may finish the events it had pending 
before the new event was posted, even those of lower priority.

[*] "implementation-defined" here means "I don't remember what it does and 
reserve the right to change it anyway".

> Context: my graceful exit procedure is designed to trigger a somewhat less
> graceful exit when a 2nd signal is delivered, for instance when the
> graceful procedure blocks (thing unresponsive remote X server). This is
> implemented with a simple std::atomic_bool state variable. When using an
> unspecified connect from the QSocketNotifier signal to my graceful exit
> procedure that principle doesn't seem to work, and even with something like
> `kill -2 $PID ; kill -1 $PID`  it is like the 2nd signal is never
> delivered. I can fix that by forcing a Qt::DirectConnection, which seems to
> be signal safe (according to a sig_atomic_t state "inSignalHandler" var)
> but is it?

QMetaObject::activate() locks a mutex, so it's not async-signal-safe. That 
means you cannot emit a Qt signal from your Unix signal handler.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center