On Monday, 8 October 2018 12:45:19 PDT Giuseppe D'Angelo via Interest wrote: > Il 08/10/2018 09:50, René J.V. Bertin ha scritto: > > That sounds real easy indeed ;) > > > >> Create a QSocketNotifier on the reading end of the pipe or on the > >> eventfd, > >> connect its activation signal to a slot that does what you want. > > > > What is the purpose of the pipe/eventfd detour? Can't I just call a > > function or signal a slot directly? > Given we're already in Linux-specific domain, also signalfd(2) comes > into mind.
Please don't use that, it's a worse solution. signalfd(2) requires that the UNIX signal in question be blocked in all threads, otherwise UNIX signal handlers take precedence over the signalfd. You can accomplish that by: a) blocking the signal in the main thread before any other threads are started (this includes the XCB event thread, so before QApplication) b) ensuring no thread unblocks the signal, so you must know what each and every library does, internally Usually you can use signalfd from the application code, but it's not an acceptable solution for a library. That's why we don't use it in Qt. But even for applications, it's not meant for complex, multi-threaded ones, just like timerfd(2) is often a worse solution that calculating your own timeouts. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center _______________________________________________ Interest mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/interest
