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

[René J.V. Bertin]

rjvbb added a comment.


  >   I would recommend to just not think about the Windows requirement, if you cannot test it anyway.
  
  You're giving a better reason below, but keeping the possible requirement in mind seems good practice to me. No one would appreciate if someone from another OS universe pushed changes that make implementing a feature harder...
  
  >   We did not have support for signal handling on Windows before
  
  I don't think that's entirely true. The only conditionals I see are the #ifdef SIG* tests, two of which are supposed to succeed on MS Windows because SIGINT and SIGTERM (unless C++ overrides the C standard in this regard).
  
  >   Why not keep it *simple* and manageable the *first* iteration to begin with? You're giving yourself a hard time...
  
  I *could* have presented the semaphore-based implementation only, of course. A semaphore seems just more natural to be used in this kind of context than doing poll() (or select() or whatever QSocketNotifier does behind the scenes) on a file descriptor to detect writes to a pipe.
  
  BTW
  
  > This KDevelop problem is not solved by saving those 2 of those file
  >  descriptors.
  
  No, but increasing the count from the start is only going to make it (a wee bit) worse - and it can make the difference between crashing (aborting) or not.
  Some BSD variants apparently still allow as little as 256 open files, and then 2 is a much less innocent number than when you basically have an unlimited open file count.
  
  But: this whole argument is moot when QtConcurrent::run() comes with a relevant and significant overhead. I haven't found evidence of that but apparently it does, so I'd have to manhandle pthread instead. Not a problem if the cross-platform argument is moot, but it requires more coding.

REPOSITORY
  R32 KDevelop

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

To: rjvbb, #kdevelop, kfunk
Cc: 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/20181015/6864da02/attachment-0001.html>