Re: [Interest] proper (silent) exit in response to SIGHUP - and signal/slot serialisation?
On Saturday, 20 October 2018 02:31:08 PDT René J. V. Bertin wrote: > So concretely, if I really wanted to call the slot before a previous call > finished I'd have to use a 2nd QSocketNotifier, possibly even watching a > second pipe? Yes, and another thread on that QSocketNotifier. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] proper (silent) exit in response to SIGHUP - and signal/slot serialisation?
Thiago Macieira wrote: >> 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. Yeah, I got things confused there. Again. Of course the Qt signal isn't sent from within the signal handler. So concretely, if I really wanted to call the slot before a previous call finished I'd have to use a 2nd QSocketNotifier, possibly even watching a second pipe? ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] proper (silent) exit in response to SIGHUP - and signal/slot serialisation?
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 ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] proper (silent) exit in response to SIGHUP - and signal/slot serialisation?
On Friday October 19 2018 16:11:34 Jason H wrote: > 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. Thanks. I think I was doing something wrong on a different level. I didn't read (in my graceful exit proc) from the pipe to which I had written in order to trigger the QSocketNotifier. Curiously I also discovered a bit later that QSocketNotifier apparently reacts to unread data on the fd/socket instead of only once to the writing of that data (Linux 4.14, Qt 5.9.6): my slot was being called repetitively in reaction to a single signal. Probably after modifying something because this does seem to contradict what I noticed earlier... Anyway, now that I read from the pipe when the slot is called everything seems to work as intended again... ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] proper (silent) exit in response to SIGHUP - and signal/slot serialisation?
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" > To: interest > 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@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest > ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
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@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] proper (silent) exit in response to SIGHUP?
On Tuesday October 16 2018 06:47:04 Kai Koehne wrote: >There's a good chance this got fixed in Qt 5.12: > > https://codereview.qt-project.org/#/c/203587/ Ah! I was already building the Assistant from the dev branch (against Qt 5.9 currently) so I should be able to test this (but only in the Assistant itself because this standalone build uses a static QtHelp library, evidently...) ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] proper (silent) exit in response to SIGHUP?
> -Original Message- > From: Interest On Behalf > Of Jean-Michaël Celerier > Sent: Sunday, October 14, 2018 7:53 AM > To: René J.V. > Cc: interest > Subject: Re: [Interest] proper (silent) exit in response to SIGHUP? > > > Add too many .qch files to a > collection and at some point the Assistant (or apps doing similar things) will > crash > > yeap, for me this makes QtCreator crash all the time on linux - fairly > frustrating, > you're writing code, want to see the doc of some class, press F1 and then > boom ! byebye qtc There's a good chance this got fixed in Qt 5.12: https://codereview.qt-project.org/#/c/203587/ Kai ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] proper (silent) exit in response to SIGHUP?
15.10.2018, 19:22, "René J. V. Bertin" : > Thiago Macieira wrote: > >> I wasn't joking. The Unix systems often copy neat features from one another >> when one innovates ahead of the others. I have a pending patch for Linux >> copying OpenBSD's O_NOSIGPIPE option but I have yet to finish it. > > So you meant "ask to incorporate this here implementation". That might work > for > Linux, possibly (Free)BSD which are open source ... but I wouldn't keep my > hopes > up with the likes of Apple. XNU kernel is also open source. -- Regards, Konstantin ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] proper (silent) exit in response to SIGHUP?
On Monday, 15 October 2018 09:22:27 PDT René J. V. Bertin wrote: > Thiago Macieira wrote: > > I wasn't joking. The Unix systems often copy neat features from one > > another > > when one innovates ahead of the others. I have a pending patch for Linux > > copying OpenBSD's O_NOSIGPIPE option but I have yet to finish it. > > So you meant "ask to incorporate this here implementation". That might work > for Linux, possibly (Free)BSD which are open source ... but I wouldn't keep > my hopes up with the likes of Apple. Indeed, so you get to pay the price for the OS not providing state-of-the-art solutions: two file descriptors per thread instead of just one. Don't complain to us about this. Complain to the vendor who can't adopt 11- year-old solutions. > > QEventDispatcherCoreFoundation. But looking at the sources, it seems that > > the event dispatcher is created on-demand by the first QEventLoop or by > > calling exec(), so the file descriptor won't be opened until then. > > So I wasn't completely blind - a thread that just lives its own life and > doesn't interact with others through Qt mechanism could do without the > pipes, but how much other overhead? The cost of a thread is much higher than the cost of a file descriptor, at least in the kernel side and in pthread itself. I recommend you read your OS sources for pthread to see if it opens file descriptors anyway -- it might, in order to signal a few things. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] proper (silent) exit in response to SIGHUP?
On 2018-10-15 16:59, Thiago Macieira wrote: On Monday, 15 October 2018 06:34:55 PDT René J. V. Bertin wrote: Thiago Macieira wrote: > Do you realise that the cost of starting a thread is much higher than the > cost of a pipe? Not to mention that using QThread will create a pipe > anyway, so you'd need to drop down to low-level primitives (pthread, > Win32) to get away from it. OK, that's an argument. I tried to figure that out and didn't see evidence that QThread *always* creates a pipe. Pity but thanks for confirming. It's not QThread itself, it's the event dispatcher. Either QEventDispatcherUNIX, QEventDispatcherGlib or, on a Mac, QEventDispatcherCoreFoundation. But looking at the sources, it seems that the event dispatcher is created on-demand by the first QEventLoop or by calling exec(), so the file descriptor won't be opened until then. It will be created regardless of event loop: https://code.woboq.org/qt5/qtbase/src/corelib/thread/qthread_unix.cpp.html#342 -- Sérgio Martins | sergio.mart...@kdab.com | Senior Software Engineer Klarälvdalens Datakonsult AB, a KDAB Group company Tel: Sweden (HQ) +46-563-540090, USA +1-866-777-KDAB(5322) KDAB - The Qt, C++ and OpenGL Experts ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] proper (silent) exit in response to SIGHUP?
Thiago Macieira wrote: > I wasn't joking. The Unix systems often copy neat features from one another > when one innovates ahead of the others. I have a pending patch for Linux > copying OpenBSD's O_NOSIGPIPE option but I have yet to finish it. So you meant "ask to incorporate this here implementation". That might work for Linux, possibly (Free)BSD which are open source ... but I wouldn't keep my hopes up with the likes of Apple. > QEventDispatcherCoreFoundation. But looking at the sources, it seems that the > event dispatcher is created on-demand by the first QEventLoop or by calling > exec(), so the file descriptor won't be opened until then. So I wasn't completely blind - a thread that just lives its own life and doesn't interact with others through Qt mechanism could do without the pipes, but how much other overhead? R. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] proper (silent) exit in response to SIGHUP?
On Monday, 15 October 2018 06:34:55 PDT René J. V. Bertin wrote: > Thiago Macieira wrote: > > You were complaining that pipes are too costly. Ok, so get your OS vendor > > to create an equivalent to Linux's eventfd() > > Sure. Dear Apple (FreeBSD), please implement eventfd() (and a bunch of other > Linux features because they make Linux so much better). I wasn't joking. The Unix systems often copy neat features from one another when one innovates ahead of the others. I have a pending patch for Linux copying OpenBSD's O_NOSIGPIPE option but I have yet to finish it. > > Do you realise that the cost of starting a thread is much higher than the > > cost of a pipe? Not to mention that using QThread will create a pipe > > anyway, so you'd need to drop down to low-level primitives (pthread, > > Win32) to get away from it. > > OK, that's an argument. I tried to figure that out and didn't see evidence > that QThread *always* creates a pipe. Pity but thanks for confirming. It's not QThread itself, it's the event dispatcher. Either QEventDispatcherUNIX, QEventDispatcherGlib or, on a Mac, QEventDispatcherCoreFoundation. But looking at the sources, it seems that the event dispatcher is created on-demand by the first QEventLoop or by calling exec(), so the file descriptor won't be opened until then. > > You could pre-allocate the event before the signal and then you can > > transfer ownership. But postEvent() still needs to manage a queue and > > that may need to > Exactly, which is what I realised when I saw it locking a mutex. Right, it also locks a mutex, which is also why it could deadlock. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] proper (silent) exit in response to SIGHUP?
Thiago Macieira wrote: > You were complaining that pipes are too costly. Ok, so get your OS vendor to > create an equivalent to Linux's eventfd() Sure. Dear Apple (FreeBSD), please implement eventfd() (and a bunch of other Linux features because they make Linux so much better). > Do you realise that the cost of starting a thread is much higher than the cost > of a pipe? Not to mention that using QThread will create a pipe anyway, so > you'd need to drop down to low-level primitives (pthread, Win32) to get away > from it. OK, that's an argument. I tried to figure that out and didn't see evidence that QThread *always* creates a pipe. Pity but thanks for confirming. > "just allocate in the actual signal handler" is exactly what you mustn't do, > since malloc() is not async-signal-safe. You can deadlock or corrupt memory if > you try that. The actual signal handler, the one that does the things you want to but cannot do in the, erm, signal handler. Sorry for the confusion. > You could pre-allocate the event before the signal and then you can transfer > ownership. But postEvent() still needs to manage a queue and that may need to Exactly, which is what I realised when I saw it locking a mutex. R ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] proper (silent) exit in response to SIGHUP?
On Saturday, 13 October 2018 01:15:00 PDT René J. V. Bertin wrote: > Thiago Macieira wrote: > > Yes, but no one uses them on Windows. In the UNIX world, they're used and > > part of system administration. > > So you're saying there's no point in trying to find an MSWin alternative for > pipe() because chances are too slim that the application would ever receive > a signal? I forgot to mention that aspect before: pipe() not being > cross-platform was another reason I have been looking for alternative > approaches. I'm saying there's no point in installing signal handlers on Windows in the first place, so you don't need to figure out how to create a pipe. Anyway, the alternative is CreateEvent and SetEvent. > If so, there's the alternative of using a semaphore (not a QSemaphore; > sem_post() is safe according to the POSIX docs) though that would probably > require a separate thread and a trick to rearm the mechanism. A Qt wrapper > around "native" semaphores could have made this easier. Or you can use an eventfd in a EFD_SEMAPHORE mode. Do you realise that the cost of starting a thread is much higher than the cost of a pipe? Not to mention that using QThread will create a pipe anyway, so you'd need to drop down to low-level primitives (pthread, Win32) to get away from it. > > Get your vendor to provide an object with a single file descriptor then. > > Sorry, vendor? Object? You were complaining that pipes are too costly. Ok, so get your OS vendor to create an equivalent to Linux's eventfd(). That was state of the art 11 years ago, so other vendors should be able to catch up or offer a reasonable alternative. > > FreeBSD: back then, FreeBSD supported more than 256 file descriptors per > > process. So I know for a fact that FreeBSD (and thus Darwin today) do > > support more. It may not be the default, so just adjust it. > > The QFSW documentation still mentions the 256 fd limit explicitly. Yes, some systems do. But you can raise the limit. > There must still be a QTBUG somewhere about the QFSW saturation in Qt4, and > then there's an open issue about QtHelp which suffers from the same open > file descriptor limit on Mac (and presumably *BSD). Add too many .qch files > to a collection and at some point the Assistant (or apps doing similar > things) will crash. I don't have access to my Mac right now so I can't > confirm whether I maxed out the open fd limit or whether the system call is > being ignored. Raise the limit! man 1 ulimit man 2 setrlimit > > allocation-free for the typical cases, your code would have to contend > > with > > the untypical case and would therefore be unsafe. > > Would it? A signal handler can be unique and work with structures that have > been preallocated. Typically you'd only need to update the signal number > which doesn't require allocating anything. Correct. That's why we use the pipe or eventfd trick. You could store more information if you wanted in a pre-allocated structure too. > I was halfway through a PoC implementation using a pre-allocated custom > QEvent when I realised that QCoreApplication::sendEvent() is apparently > synchronous so I'd need QCoreApplication::postEvent(). And that one does > all kind of unsafe things. Transferring ownership of the QEvent wouldn't be > a problem (just allocate a new one in the actual signal handler, if needed) > but postEvent() also locks a mutex. "just allocate in the actual signal handler" is exactly what you mustn't do, since malloc() is not async-signal-safe. You can deadlock or corrupt memory if you try that. You could pre-allocate the event before the signal and then you can transfer ownership. But postEvent() still needs to manage a queue and that may need to allocate memory. To support an allocation-free event posting, we'd need to make sure the queue always has some buffer free and since this buffer can't be managed by malloc(), we conclude it must be a static buffer that must never be allowed to fill. Except when we want to fill it. So immediate corollary is that posting from a Unix signal handler necessarily requires a function other than postEvent(). Which in turn means this doesn't need to be in Qt at all. Simply create your own event store and write to that from your signal handler. You can wake up the thread by using QAbstractEventDispatcher::instance(thread)->wakeUp(); [note how that *is* writing to a pipe or an eventfd] The next thing is to make sure you get to check your buffer from that thread at opportune moments. For example, you can use a periodic timer or connect a slot to the dispatcher's awake() signal. I recommend the latter. Note you'll be trading application memory and CPU cycles on *every* *event* *loop* for a pipe. Is that worth the cost? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-proj
Re: [Interest] proper (silent) exit in response to SIGHUP?
On Sunday, 14 October 2018 02:28:50 PDT René J.V. Bertin wrote: > Back to the original topic: I've been trying to follow what goes on when > using QtConcurrent::run; how many file descriptors does this open (or using > a QThread in general), on average? One file descriptor per thread on Linux, two on other OSes. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] proper (silent) exit in response to SIGHUP?
On Sunday October 14 2018 12:52:52 Jean-Michaël Celerier wrote: >quite a bunch, I've got them for the Qt versions I target (5.6, 5.9, 5.11 >and sometimes the beta) I've never been that adventurous yet :) But is it even that useful to have so many Qt versions in a single qthelp collection? I find that the v5 documentation is pretty good at showing which version introduced a given API so you could probably do with just the 5.11 documentation, no? >But I already had to incread my ulimit maximums quita a bit to be able to >handle all of this. Mine are supposed to be maxed out too. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] proper (silent) exit in response to SIGHUP?
> What, also on Linux? How many qhc files do you have configured (imported) in Creator? quite a bunch, I've got them for the Qt versions I target (5.6, 5.9, 5.11 and sometimes the beta) + KDE Frameworks + CMake + cppreference + two additional qchs for the software I work on. At some point I also had OpenCV's. But I already had to incread my ulimit maximums quita a bit to be able to handle all of this. --- Jean-Michaël Celerier http://www.jcelerier.name On Sun, Oct 14, 2018 at 11:28 AM René J.V. Bertin wrote: > On Sunday October 14 2018 07:52:39 Jean-Michaël Celerier wrote: > > >yeap, for me this makes QtCreator crash all the time on linux - fairly > >frustrating, you're writing code, want to see the doc of some class, press > >F1 and then boom ! byebye qtc > > What, also on Linux? How many qhc files do you have configured (imported) > in Creator? > > On Mac I can hardly have the full collection of Qt's own component .qhc > files (even in the Assistant) - for a single Qt version. > This is the ticket in question: > https://bugreports.qt.io/browse/QTBUG-59664 > > Back to the original topic: I've been trying to follow what goes on when > using QtConcurrent::run; how many file descriptors does this open (or using > a QThread in general), on average? > > R. > ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] proper (silent) exit in response to SIGHUP?
On Sunday October 14 2018 07:52:39 Jean-Michaël Celerier wrote: >yeap, for me this makes QtCreator crash all the time on linux - fairly >frustrating, you're writing code, want to see the doc of some class, press >F1 and then boom ! byebye qtc What, also on Linux? How many qhc files do you have configured (imported) in Creator? On Mac I can hardly have the full collection of Qt's own component .qhc files (even in the Assistant) - for a single Qt version. This is the ticket in question: https://bugreports.qt.io/browse/QTBUG-59664 Back to the original topic: I've been trying to follow what goes on when using QtConcurrent::run; how many file descriptors does this open (or using a QThread in general), on average? R. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] proper (silent) exit in response to SIGHUP?
> Add too many .qch files to a collection and at some point the Assistant (or apps doing similar things) will crash yeap, for me this makes QtCreator crash all the time on linux - fairly frustrating, you're writing code, want to see the doc of some class, press F1 and then boom ! byebye qtc --- Jean-Michaël Celerier http://www.jcelerier.name On Sat, Oct 13, 2018 at 10:15 AM René J. V. Bertin wrote: > Thiago Macieira wrote: > > > Yes, but no one uses them on Windows. In the UNIX world, they're used > and part > > of system administration. > > So you're saying there's no point in trying to find an MSWin alternative > for > pipe() because chances are too slim that the application would ever > receive a > signal? I forgot to mention that aspect before: pipe() not being > cross-platform > was another reason I have been looking for alternative approaches. > > If so, there's the alternative of using a semaphore (not a QSemaphore; > sem_post() is safe according to the POSIX docs) though that would probably > require a separate thread and a trick to rearm the mechanism. A Qt wrapper > around "native" semaphores could have made this easier. > > > C also leaves unspecified how signal delivery interacts with > multithreading. > > POSIX does clarify that. But Windows isn't a POSIX system, so the rules > don't > > applyt hrere. > > Apparently you can't use SIGINT the same way as elsewhere because it makes > a > single-threaded application multi-threaded. I haven't done any windev > since XP > but I read that particular point as moot for multi-threaded apps. > > > Get your vendor to provide an object with a single file descriptor then. > > Sorry, vendor? Object? > > > And here's why I know this: because when I started learning about Linux, > > *this* was the reason why the DALNet IRC servers were switching from > Linux to > > Well, this is not about which OS is better than which other OS :) > > > FreeBSD: back then, FreeBSD supported more than 256 file descriptors per > > process. So I know for a fact that FreeBSD (and thus Darwin today) do > support > > more. It may not be the default, so just adjust it. > > The QFSW documentation still mentions the 256 fd limit explicitly. > > Darwin is *not* FreeBSD (can't remember which other flavour) though > apparently it > was "synchronised with FreeBSD 5" for the release of 10.3.0; and of course > it > has a completely different kernel beast. > There must still be a QTBUG somewhere about the QFSW saturation in Qt4, > and then > there's an open issue about QtHelp which suffers from the same open file > descriptor limit on Mac (and presumably *BSD). Add too many .qch files to > a > collection and at some point the Assistant (or apps doing similar things) > will > crash. I don't have access to my Mac right now so I can't confirm whether > I maxed > out the open fd limit or whether the system call is being ignored. > > > > > Not from the documentation, but it's logical. > > That's what I meant, it's logical with hindsight. > > > allocation-free for the typical cases, your code would have to contend > with > > the untypical case and would therefore be unsafe. > > Would it? A signal handler can be unique and work with structures that > have been > preallocated. Typically you'd only need to update the signal number which > doesn't require allocating anything. > > I was halfway through a PoC implementation using a pre-allocated custom > QEvent > when I realised that QCoreApplication::sendEvent() is apparently > synchronous so > I'd need QCoreApplication::postEvent(). And that one does all kind of > unsafe > things. Transferring ownership of the QEvent wouldn't be a problem (just > allocate a new one in the actual signal handler, if needed) but > postEvent() also > locks a mutex. > > R. > > ___ > Interest mailing list > Interest@qt-project.org > http://lists.qt-project.org/mailman/listinfo/interest > ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] proper (silent) exit in response to SIGHUP?
So I think I have an alternative implementation that ought to be more straightforward to port to MS Windows if ever that is necessary, one that I think (hope) is safe: https://github.com/RJVB/shortcut-test-qt5/blob/master/main.cpp#L96 This uses a single semaphore and a QtConcurrent background thread that "monitors" it. I think it's hardly more complex than using the pipe+QSocketNotifier solution (and could be simpler if it weren't apparently a good idea to destroy the semaphore before exiting). Curiously, the manpage suggest that sem_wait() should be interrupted by a signal, and that's indeed the case in a single-threaded test-case. Pity, because it would have made the call to sem_post() superfluous in the actual signal handler... R. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] proper (silent) exit in response to SIGHUP?
FWIW, a quick check on my current FreeBSD-based system (TrueOS) shows a per- process open file limit of 87975, which seems hard to reach. Yet I'm sure I've managed with KDevelop 4 and its 1-QFSW-per-project-file approach... ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] proper (silent) exit in response to SIGHUP?
Thiago Macieira wrote: > Yes, but no one uses them on Windows. In the UNIX world, they're used and part > of system administration. So you're saying there's no point in trying to find an MSWin alternative for pipe() because chances are too slim that the application would ever receive a signal? I forgot to mention that aspect before: pipe() not being cross-platform was another reason I have been looking for alternative approaches. If so, there's the alternative of using a semaphore (not a QSemaphore; sem_post() is safe according to the POSIX docs) though that would probably require a separate thread and a trick to rearm the mechanism. A Qt wrapper around "native" semaphores could have made this easier. > C also leaves unspecified how signal delivery interacts with multithreading. > POSIX does clarify that. But Windows isn't a POSIX system, so the rules don't > applyt hrere. Apparently you can't use SIGINT the same way as elsewhere because it makes a single-threaded application multi-threaded. I haven't done any windev since XP but I read that particular point as moot for multi-threaded apps. > Get your vendor to provide an object with a single file descriptor then. Sorry, vendor? Object? > And here's why I know this: because when I started learning about Linux, > *this* was the reason why the DALNet IRC servers were switching from Linux to Well, this is not about which OS is better than which other OS :) > FreeBSD: back then, FreeBSD supported more than 256 file descriptors per > process. So I know for a fact that FreeBSD (and thus Darwin today) do support > more. It may not be the default, so just adjust it. The QFSW documentation still mentions the 256 fd limit explicitly. Darwin is *not* FreeBSD (can't remember which other flavour) though apparently it was "synchronised with FreeBSD 5" for the release of 10.3.0; and of course it has a completely different kernel beast. There must still be a QTBUG somewhere about the QFSW saturation in Qt4, and then there's an open issue about QtHelp which suffers from the same open file descriptor limit on Mac (and presumably *BSD). Add too many .qch files to a collection and at some point the Assistant (or apps doing similar things) will crash. I don't have access to my Mac right now so I can't confirm whether I maxed out the open fd limit or whether the system call is being ignored. > Not from the documentation, but it's logical. That's what I meant, it's logical with hindsight. > allocation-free for the typical cases, your code would have to contend with > the untypical case and would therefore be unsafe. Would it? A signal handler can be unique and work with structures that have been preallocated. Typically you'd only need to update the signal number which doesn't require allocating anything. I was halfway through a PoC implementation using a pre-allocated custom QEvent when I realised that QCoreApplication::sendEvent() is apparently synchronous so I'd need QCoreApplication::postEvent(). And that one does all kind of unsafe things. Transferring ownership of the QEvent wouldn't be a problem (just allocate a new one in the actual signal handler, if needed) but postEvent() also locks a mutex. R. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] proper (silent) exit in response to SIGHUP?
On Friday, 12 October 2018 11:37:52 PDT René J. V. Bertin wrote: > Thiago Macieira wrote: > > They're not. They're just the first link I found when googling for "signal > > safe". The official list comes from POSIX. > > I did some homework of my own. Turns out these signals are also known as > "ANSI signals" or "standard C signals" and are actually part of standard > (at least some, including SIGINT and SIGTERM, but not SIGHUP). So they do > exist on MS Windows. With very similar limitations, even. Yes, but no one uses them on Windows. In the UNIX world, they're used and part of system administration. C also leaves unspecified how signal delivery interacts with multithreading. POSIX does clarify that. But Windows isn't a POSIX system, so the rules don't applyt hrere. > > QFSW on BSD uses kqueue, so one fd per QFSW. > > Indeed, so in something like an IDE that wants to monitor an entire source > tree for changes you quickly run out of available file descriptors (was the > case too with Qt4 on Mac). That can be catastrophic (QThreadPipe will start > failing). That's the reason I was hoping to be clever and use something > other than a set of 2 file descriptors for an anonymous pipe. Get your vendor to provide an object with a single file descriptor then. Linux did that on version 2.6.23, 11 years ago. eventfd are cheaper than pipes on the kernel side too, as they only consume 8 bytes of storage (plus overhead), instead of a 128 kB buffer. Another interesting tidbit is that Linux hasn't used 256 fds per process since the 2.0.x kernel series. That's over 20 years ago. And even in the 2.0 series it could be increased if you recompiled the kernel, unlike in the 1.2 series. And here's why I know this: because when I started learning about Linux, *this* was the reason why the DALNet IRC servers were switching from Linux to FreeBSD: back then, FreeBSD supported more than 256 file descriptors per process. So I know for a fact that FreeBSD (and thus Darwin today) do support more. It may not be the default, so just adjust it. > > Trivia: FreeBSD has eventfd, but it's not available for FreeBSD-native > > applications. It's only available for Linux ones. > > Hmmm, I thought epoll-shim provided an implementation? I meant a native implementation of eventfd, with the same semantics. But there's no system call to access them from a FreeBSD-native process. You can only get to it by way of the Linux emulation. > > If you meant "emit a signal", then it's one of the two: > Yes, a queued connection, evidently. It's not immediately evident from the > documentation that this allocates memory (if you don't already know it). Not from the documentation, but it's logical. It's a *queued* connection, so something needs to be added to a queue. It's that which allocates memory. There's no allocation-free queue data structure, at least not one that can handle up to thousands of events stored and queued. Even if we made it allocation-free for the typical cases, your code would have to contend with the untypical case and would therefore be unsafe. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] proper (silent) exit in response to SIGHUP?
Thiago Macieira wrote: > They're not. They're just the first link I found when googling for "signal > safe". The official list comes from POSIX. I did some homework of my own. Turns out these signals are also known as "ANSI signals" or "standard C signals" and are actually part of standard (at least some, including SIGINT and SIGTERM, but not SIGHUP). So they do exist on MS Windows. With very similar limitations, even. > QFSW on BSD uses kqueue, so one fd per QFSW. Indeed, so in something like an IDE that wants to monitor an entire source tree for changes you quickly run out of available file descriptors (was the case too with Qt4 on Mac). That can be catastrophic (QThreadPipe will start failing). That's the reason I was hoping to be clever and use something other than a set of 2 file descriptors for an anonymous pipe. > Trivia: FreeBSD has eventfd, but it's not available for FreeBSD-native > applications. It's only available for Linux ones. Hmmm, I thought epoll-shim provided an implementation? > If you meant "emit a signal", then it's one of the two: Yes, a queued connection, evidently. It's not immediately evident from the documentation that this allocates memory (if you don't already know it). R. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] proper (silent) exit in response to SIGHUP?
On Friday, 12 October 2018 00:26:44 PDT René J. V. Bertin wrote: > Thiago Macieira wrote: > > So I got to thinking: how Linux-specific if not exclusive are the guidelines > you pointed me to > (http://man7.org/linux/man-pages/man7/signal-safety.7.html)? They're not. They're just the first link I found when googling for "signal safe". The official list comes from POSIX. http://pubs.opengroup.org/onlinepubs/9699919799/functions/ V2_chap02.html#tag_15_04 > > Open a pipe or an eventfd, then install your signal handler. In that > > signal > > handler, write anything to the writing end or write uint64_t(1) the > > eventfd. Create a QSocketNotifier on the reading end of the pipe or on > > the eventfd, > Evenfd is Linux-only AFAIK, and opening 2 file descriptors is relatively > costly on *BSD (which have like a 256 fd per-process limit) if you also > want to use as many QFileSystemWatchers as possible. QFSW on BSD uses kqueue, so one fd per QFSW. Trivia: FreeBSD has eventfd, but it's not available for FreeBSD-native applications. It's only available for Linux ones. > Finally: why use a QSocketNotifier that sends a signal to a slot, how is > that different from sending the signal directly from the signal handler > function? If you meant "emit a signal", then it's one of the two: a) direct connection - well, then why didn't you put the contents of your shut down in the UNIX signal handler in the first place? There was a reason. b) queued connection - allocates memory -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] proper (silent) exit in response to SIGHUP?
On Friday, 12 October 2018 06:11:16 PDT René J. V. Bertin wrote: > Dang... I guess that would be QEvent::MetaCall? Is there a way to prepare > that event beforehand and send it as a synthetic event it inside the event > handler instead of doing an emit? Why do you want a more complex solution? Just write to the pipe, that's the cheapest solution. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] proper (silent) exit in response to SIGHUP?
Giuseppe D'Angelo via Interest wrote: > It's not safe. Emitting a signal with a queued invocation will allocate > memory. So don't do it from a signal handler. Ah yes, Qt needs to copy the arguments to store them in an event behind the scenes Dang... I guess that would be QEvent::MetaCall? Is there a way to prepare that event beforehand and send it as a synthetic event it inside the event handler instead of doing an emit? Not that I know if it's safe to UNlock a mutex or release a semaphore in a signal handler, but I'm a bit surprised that I can't find a class like QWaitCondition that emit a signal when the condition is met. R. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] proper (silent) exit in response to SIGHUP?
Hi, Il 12/10/2018 10:58, René J. V. Bertin ha scritto: Did some backtracing in a debugger; I get an almost identical backtrace from the event loop (and not the signal handler) when I call my slot - through a QSocketNotifier (after writing to a pipe) - through a QueuedConnection connection invoked from an emit in the signal handler The latter solution also makes it more straightforward to pass the signal number to the actual handler. Is this safe? If it is, wouldn't it be a nice little addition to QCoreApplication? It's not safe. Emitting a signal with a queued invocation will allocate memory. So don't do it from a signal handler. My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] proper (silent) exit in response to SIGHUP?
René J. V. Bertin wrote: > Finally: why use a QSocketNotifier that sends a signal to a slot, how is that > different from sending the signal directly from the signal handler function? Did some backtracing in a debugger; I get an almost identical backtrace from the event loop (and not the signal handler) when I call my slot - through a QSocketNotifier (after writing to a pipe) - through a QueuedConnection connection invoked from an emit in the signal handler The latter solution also makes it more straightforward to pass the signal number to the actual handler. Is this safe? If it is, wouldn't it be a nice little addition to QCoreApplication? R. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] proper (silent) exit in response to SIGHUP?
Thiago Macieira wrote: So I got to thinking: how Linux-specific if not exclusive are the guidelines you pointed me to (http://man7.org/linux/man-pages/man7/signal-safety.7.html)? > Open a pipe or an eventfd, then install your signal handler. In that signal > handler, write anything to the writing end or write uint64_t(1) the eventfd. > Create a QSocketNotifier on the reading end of the pipe or on the eventfd, Evenfd is Linux-only AFAIK, and opening 2 file descriptors is relatively costly on *BSD (which have like a 256 fd per-process limit) if you also want to use as many QFileSystemWatchers as possible. (There's also MS Windows but I presume its signal handling is completely different anyway...) Finally: why use a QSocketNotifier that sends a signal to a slot, how is that different from sending the signal directly from the signal handler function? Thanks, R. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] proper (silent) exit in response to SIGHUP?
On Wednesday, 10 October 2018 00:50:10 PDT René J. V. Bertin wrote: > Thiago Macieira wrote: > > You can call _exit. You can't call much else. You can only call the > > functions listed in this man page from a signal handler: > > http://man7.org/linux/man-pages/man7/signal-safety.7.html > > > > NEVER allocate memory and NEVER lock a mutex in a signal handler. > > So you are basically saying that KDevelop is doing it all wrong and that > it's purely by chance that this works (when the X server is responsive)? > > https://github.com/KDE/kdevelop/blob/master/kdevplatform/shell/core.cpp#L54 > > (not looking to point fingers, just to know if there's room for improvement) Yes. That code is a timebomb waiting to go off. Or maybe a better metaphor is a Russian roulette, since it depends on what the other threads are doing, meaning you can be lucky most of the time. The qCDebug and QApplication::closeAllWindows allocate memory, so they can deadlock inside malloc(). QCoreApplication::quit() doesn't, but it's not async-signal safe either. > And a complementary question: why does QXcbConnection::processXcbEvents() > call exit() when the X server (probably) died, if that's not supposed to > work? It's not supposed to, but at that point it's the least of our worries. The application no longer has a GUI, so it can't display anything anyway for the user. If it crashes, that's fine: it'll just be one more core file that your system will capture, after X's. The worst case scenario is if it deadlocks, but systemd will probably kill it anyway as the user session is exiting. > I wonder if that explains why I sometimes see evidence of Qt applications > that crashed after an X server went down. It could. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] proper (silent) exit in response to SIGHUP?
And a complementary question: why does QXcbConnection::processXcbEvents() call exit() when the X server (probably) died, if that's not supposed to work? I wonder if that explains why I sometimes see evidence of Qt applications that crashed after an X server went down. R. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] proper (silent) exit in response to SIGHUP?
Thiago Macieira wrote: > You can call _exit. You can't call much else. You can only call the functions > listed in this man page from a signal handler: > http://man7.org/linux/man-pages/man7/signal-safety.7.html > > NEVER allocate memory and NEVER lock a mutex in a signal handler. So you are basically saying that KDevelop is doing it all wrong and that it's purely by chance that this works (when the X server is responsive)? https://github.com/KDE/kdevelop/blob/master/kdevplatform/shell/core.cpp#L54 (not looking to point fingers, just to know if there's room for improvement) R. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] proper (silent) exit in response to SIGHUP?
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 Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] proper (silent) exit in response to SIGHUP?
On Monday, 8 October 2018 10:46:31 PDT René J.V. Bertin wrote: > Thiago Macieira wrote: > >> What is the purpose of the pipe/eventfd detour? Can't I just call a > >> function or signal a slot directly? > > > > You can call _exit. You can't call much else. You can only call the > > functions > OK, got it. > > I take it that the QSocketNotifier lives on the main thread and connects to > a slot that lives there too, somehow preventing the signal handler from > returning which could lead to the application exitting prematurely? The slot can live in any thread, but yes in general you'd place it in the main thread. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] proper (silent) exit in response to SIGHUP?
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. My 2 c, -- Giuseppe D'Angelo | giuseppe.dang...@kdab.com | Senior Software Engineer KDAB (France) S.A.S., a KDAB Group company Tel. France +33 (0)4 90 84 08 53, http://www.kdab.com KDAB - The Qt, C++ and OpenGL Experts smime.p7s Description: Firma crittografica S/MIME ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] proper (silent) exit in response to SIGHUP?
Thiago Macieira wrote: >> What is the purpose of the pipe/eventfd detour? Can't I just call a function >> or signal a slot directly? > > You can call _exit. You can't call much else. You can only call the functions OK, got it. I take it that the QSocketNotifier lives on the main thread and connects to a slot that lives there too, somehow preventing the signal handler from returning which could lead to the application exitting prematurely? R. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] proper (silent) exit in response to SIGHUP?
On Monday, 8 October 2018 00:50:50 PDT René J.V. Bertin wrote: > Thiago Macieira wrote: > > 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? You can call _exit. You can't call much else. You can only call the functions listed in this man page from a signal handler: http://man7.org/linux/man-pages/man7/signal-safety.7.html NEVER allocate memory and NEVER lock a mutex in a signal handler. > > Exiting with exit() is not expected to work with Qt. Normal exit must > > return from main(), so you should simply ask the QCoreApplication main > > event loop to exit (quit() slot). > > A KDE dev told me a SIGHUP should already work (contrary to my experience). > So I tried it on a complex app running locally and it turns out that it > indeed went through its regular shut-down cycle. Including unsaved file > alerts. That might be a KF5 add-on. Qt doesn't do that by itself. > This sort of YMMV is why I didn't wonder aloud why Qt doesn't attempt to > catch SIGHUP itself, to invoke QCoreApplication::quit. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] proper (silent) exit in response to SIGHUP?
Thiago Macieira wrote: 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? > Exiting with exit() is not expected to work with Qt. Normal exit must return > from main(), so you should simply ask the QCoreApplication main event loop to > exit (quit() slot). A KDE dev told me a SIGHUP should already work (contrary to my experience). So I tried it on a complex app running locally and it turns out that it indeed went through its regular shut-down cycle. Including unsaved file alerts. > But if you wanted that, you wouldn't need to add a signal handler, since > SIGHUP's default behaviour is to terminate the application. True, though I'm not sure how picky one can be if you want to avoid attempts at interaction with the user. I'd expect that calling the dtor on an instance of a document class holding an unsaved document would trigger "do you want to save this file" dialog. Dtors in the XCB plugin could well try to close down properly, making calls that block if the remote server has become unavailable. This sort of YMMV is why I didn't wonder aloud why Qt doesn't attempt to catch SIGHUP itself, to invoke QCoreApplication::quit. R. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
Re: [Interest] proper (silent) exit in response to SIGHUP?
On Sunday, 7 October 2018 00:48:01 PDT René J.V. Bertin wrote: > Hi, > > How feasible would it be to implement a SIGHUP handler that triggers a > proper, silent/non-interactive exit? It's not very difficult. Open a pipe or an eventfd, then install your signal handler. In that signal handler, write anything to the writing end or write uint64_t(1) the eventfd. 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. That's it. > I presume the problem isn't very hard for applications running locally > (though I might be overlooking something). However, I mostly have the XCB > QPA in mind here, and applications running remotely on an X11 server that > becomes unresponsive or unavailable (network issue, or remote host > suspended). Does the regular shutdown procedure under X11 contain calls > that would block indefinitely and if so, is there a way to circumvent this > procedure (calling exit() or _exit() after some custom save-what-you-can > cleanup)? I'd presume that similar interrogations can be made for other > QPAs allowing remote displaying - the VNC QPA and possibly Wayland? Exiting with exit() is not expected to work with Qt. Normal exit must return from main(), so you should simply ask the QCoreApplication main event loop to exit (quit() slot). _exit() is a valid alternative, but note it won't save any files or flush any buffers or run destructors. But if you wanted that, you wouldn't need to add a signal handler, since SIGHUP's default behaviour is to terminate the application. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
[Interest] proper (silent) exit in response to SIGHUP?
Hi, How feasible would it be to implement a SIGHUP handler that triggers a proper, silent/non-interactive exit? I presume the problem isn't very hard for applications running locally (though I might be overlooking something). However, I mostly have the XCB QPA in mind here, and applications running remotely on an X11 server that becomes unresponsive or unavailable (network issue, or remote host suspended). Does the regular shutdown procedure under X11 contain calls that would block indefinitely and if so, is there a way to circumvent this procedure (calling exit() or _exit() after some custom save-what-you-can cleanup)? I'd presume that similar interrogations can be made for other QPAs allowing remote displaying - the VNC QPA and possibly Wayland? I'll experiment a bit with this myself but would appreciate a heads-up if I'm pursuing a lost cause here. Thanks, R. ___ Interest mailing list Interest@qt-project.org http://lists.qt-project.org/mailman/listinfo/interest
