D16218: [KDevelop/Core]: safe signal-handler implementation (WIP)

[René J.V. Bertin]

rjvbb added a comment.


  Still working on this and waiting on more background info from the Qt Interest ML.
  
  Somehow I missed that the 2-stage design cannot work (or it stopped working for some reason) when proxying interrupt signals over a QSocketNotifier signal/slot mechanism. I thought I had tested that with my semaphore-based implementation, but this *would* also be another effect of Qt's event loop queueing slot evocations instead of invoking them "recursively".
  
  Indeed, when I use a non-specified connection from the QSocketNotifier signal the second signal never makes it into the graceful exit procedure when I do
  
  > kill -2 $PID ; sleep 1 ; kill -1 $PID
  
  The actual signal handler does see all signals, of course, and the 2nd signal is the one seen by the graceful procedure when I do
  
  > kill -2 $PID ; kill -1 $PID
  
  FWIW, I also tried reading from the pipe to see if something at that level was blocking the 2nd signal, and if an explicit Qt::DirectConnection made a difference. Not.
  
  So I may yet have to implement a more basic approach: resetting the signal handling (signal(sig, SIG_DFL)) in the actual signal handler.

REPOSITORY
  R32 KDevelop

REVISION DETAIL
  https://phabricator.kde.org/D16218

To: rjvbb, #kdevelop, kfunk
Cc: aaronpuchert, brauch, kfunk, arrowd, kdevelop-devel, glebaccon, antismap, iodelay, vbspam, geetamc, Pilzschaf, akshaydeo, surgenight
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdevelop-devel/attachments/20181019/3d54af3c/attachment.html>