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

[Jason H]

There are two ways:
By direct invocation (same thread only)
Or 
By inserting an event into an event loop of the appropriate thread (same or different thread).  
Queued connection just ensures that if direction invocation is available, that it is not used. I've only ever had to use this once in my life.


> Sent: Friday, October 19, 2018 at 4:39 AM
> From: "René J.V. Bertin" <rjvbertin at gmail.com>
> To: interest <interest at qt-project.org>
> Subject: Re: [Interest] proper (silent) exit in response to SIGHUP - and signal/slot serialisation?
>
> 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?
> 
> 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?
> 
> Thnks,
> R.
> _______________________________________________
> Interest mailing list
> Interest at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/interest
>