Re: [Development] Are SiCs through #include cleanups considered acceptable?
Am 10.04.2015 um 17:51 schrieb Thiago Macieira:
On Friday 10 April 2015 09:51:42 Christian Kandeler wrote:
On 04/09/2015 08:51 PM, Thiago Macieira wrote:
The objective is to make Qt6 QStringList be a typedef to QListQString,
not a separate class.
Uh-oh, that will break all forward declarations in client code...
Ok, I hadn't considered that...
So we finally have reached the turning point at which we have no chance
but to make C++11 mandatory for public Qt headers:
class QStringList : public QListQString
{
public:
using QList::QList;
};
/wishful-troll :-)
Ciao,
Mathias
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Are SiCs through #include cleanups considered acceptable?
On 14/04/15 08:36, Mathias Hasselmann math...@taschenorakel.de wrote: Am 10.04.2015 um 17:51 schrieb Thiago Macieira: On Friday 10 April 2015 15:03:04 André Somers wrote: I do think it needs a bit of work on the documentation side of things to make it clear that really any QListQByteArray now behaves as/is a QByteArrayList. The documentation still says it is a class. For documentation purposes only. Is lying to the user really the proper approach for documentation? I'd totally prefer if the documentation tells the user that special methods are available for QList specializations. Agree. Currently I believe qdoc can’t handle template specializations properly though. So we’ll need to fix that part first. In the meantime, we could add a sentence inside the QByteArrayList docs saying that it’s in reality a typedef. Cheers, Lars ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Are SiCs through #include cleanups considered acceptable?
Am 10.04.2015 um 17:51 schrieb Thiago Macieira: On Friday 10 April 2015 15:03:04 André Somers wrote: I do think it needs a bit of work on the documentation side of things to make it clear that really any QListQByteArray now behaves as/is a QByteArrayList. The documentation still says it is a class. For documentation purposes only. Is lying to the user really the proper approach for documentation? I'd totally prefer if the documentation tells the user that special methods are available for QList specializations. Ciao, Mathias ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Allowing event delivery prior to and after QCoreApplication
On Monday April 13 2015 21:12:58 Thiago Macieira wrote: Hello, I'd like some opinions on whether we should try this or not. Note another problem: if a thread is running and delivering events while the QCoreApplication gets destroyed, the application will have several race conditions: 1) data races accessing QCoreApplicationPrivate::is_app_closing 2) TOCTOU race in QCoreApplication::sendEvent for the existence of QCoreApplication So I have to ask: do we NEED to use QCoreApplication::notify() virtual outside the main thread? Not that I have any intimate knowledge of the inner workings you're discussing, but this sounds like the kind of situation ObjC avoids with its retain/release scheme. Would it help if you somehow imposed such a scheme on central classes like QCoreApplication? R. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Are SiCs through #include cleanups considered acceptable?
On Tuesday 14. April 2015 08.33.06 Mathias Hasselmann wrote: So we finally have reached the turning point at which we have no chance but to make C++11 mandatory for public Qt headers: You might think you're trolling, but I think requiring C++11 would be an excellent goal for Qt 6. - Paul ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] New Qt 4.8.7 snapshot build is available
On Monday April 13 2015 22:11:51 René J.V. Bertin wrote: The culprit is probably the failure to find filterIncludePath and filterLibraryPath . Where are those supposed to be found? I think I found my answer: http://git.buildroot.net/buildroot/diff/?id=b37f428bacdca7859fb0b678ec9658cbccaa359a (and a bug report thus seems to be unnecessary). R. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Allowing event delivery prior to and after QCoreApplication
On Tuesday 14 April 2015 17:53:20 René J.V. Bertin wrote: This may be an open door, but couldn't you change the application's entry point (or provide an alternative entry point like KDE does with kdemain). That gives you an extra layer around what the user sees as the main function. I don't see how that is beneficial to anything here. It's at best a no-op. Combine that with a modified private class with a d pointer that does not necessarily get deleted when the Q*Application dtor is called, and you may have a solution? You won't be breaking any applications, and users can decide for themselves if/when they change their code to make use of the new approach. The problem is not the d pointer or the private class. The problem is the public, *user* class if they derived from QApplication. If they've overridden notify(), then I need to know when the *user* class begins destruction so that we stop calling notify(). Robert's solution would allow for it, but at the expense of being source incompatible with every single Qt application. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Allowing event delivery prior to and after QCoreApplication
On Tuesday 14 April 2015 16:26:19 Simon Hausmann wrote:
Would it be feasible to make event loops started before and after
QCoreApplication truly independent from notify() but all the others join
in?
Not without race conditions.
if (self)
return self-notify(object, event);
// deliver directly
return doNotify(object, event);
What happens if the QCoreApplication gets deleted between the first and second
lines? In fact, what happens if it begins destruction? That's totally in the
land of undefined behaviour.
I'm not introducing the race condition, it already exists:
inline bool QCoreApplication::sendEvent(QObject *receiver, QEvent *event)
{ if (event) event-spont = false; return self ? self-
notifyInternal(receiver, event) : false; }
I only three possible outcomes here:
1) ignore the problem and document it that Qt event delivery is unsafe if you
have any threads running by the time QCoreApplication gets deleted
2) fix it by not passing through notify() outside the main thread. That's the
solution I implemented in I27eaacb532114dd188c413d4ad2a4bb443e6.
3) introduce a global, recursive QReadWriteLock that prevents QCoreApplication
destruction from concluding. Note that it cannot prevent the destruction from
starting, so the virtual table may still change and we are still in undefined
behaviour by calling a virtual after the object began destructing.
I recommend against 1 and 3
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Allowing event delivery prior to and after QCoreApplication
On Tuesday April 14 2015 08:27:57 Thiago Macieira wrote: C++ already has that, it's called reference counting. You may have heard we use it in Qt :-) Well, reference counting can be used for many things (like deleteLater, I presume) :) The problem here is that QCoreApplication is not reference counted and we can't change it without breaking *every* *single* *application*, since this is what people usually do: That stack declaration is the problem here. The app object will be destroyed at the closing brace, whether we want it or not, and there's nothing we can do to prevent it, delay it or even hook something as it begins. Yes, the issue is that C++ does an immediate delete that you cannot really cancel. This may be an open door, but couldn't you change the application's entry point (or provide an alternative entry point like KDE does with kdemain). That gives you an extra layer around what the user sees as the main function. Combine that with a modified private class with a d pointer that does not necessarily get deleted when the Q*Application dtor is called, and you may have a solution? You won't be breaking any applications, and users can decide for themselves if/when they change their code to make use of the new approach. R. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Allowing event delivery prior to and after QCoreApplication
2015-04-14 16:36 GMT+02:00 Thiago Macieira thiago.macie...@intel.com: 2) fix it by not passing through notify() outside the main thread. That's the solution I implemented in I27eaacb532114dd188c413d4ad2a4bb443e6. People rely on QCoreApplication::notify to provide a try/catch when working with Qt and exceptions. That allows dealing with them in a single place, rather than in every single function called by a Qt event. If it stops working in threads, some applications will definitely see the difference. They won't necessarily break, as I seem to remember Qt has a generic try/catch around notify, but they will loose any information from the exception. Is it that common to destroy the application object will threads are still delivering events ? It feels weird to me... It would be a shame to fix a uncommon case by breaking a common one. Just thinking out loud, but assuming it isn't that common, would it make sense to provide a setting to choose between the two behaviors ? Or a Qt function/slot one need to explicitly call from the most derived application destructor when needing to continue processing events ? Or provide a different way of creating/destroying the application object when this behavior is required ? Julien Cugnière ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML bindings for native Android controls
On Tue, Apr 14, 2015 at 1:14 PM, Jeremy Lainé jeremy.la...@m4x.org wrote: On 04/13/2015 03:46 PM, Nurmi J-P wrote: On 13 Apr 2015, at 14:50, Jeremy Lainé jeremy.la...@m4x.org wrote: How about just android-controls, which would become qt-android-controls if the project graduates from playground? I like this suggestion. In the end we will have much more (*) than just UI controls, though. Does that matter from the naming perspective? *) For example, good background service integration is important for my own use cases. Pretty much the same way WorkerScript works, I hope to be able to send arbitrary jsobjects between background services and UI instances. Another option is quick-android, which would become qt-quick-android. Cheers, Jeremy +1 I would love to try this so any name is good for me. I was just starting to develop something for android (in java) just because qtquickcontrols doesn't feel right. This however is really encouraging. Do/will the standard Qt models work with the native views? ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML bindings for native Android controls
On 14 Apr 2015, at 19:45, Nicolás Ulrich nikola...@gmail.com wrote: I would love to try this so any name is good for me. I was just starting to develop something for android (in java) just because qtquickcontrols doesn't feel right. This however is really encouraging. This is looking very promising, but don’t get too excited yet. :) This is not a finished product, just a hackathon project that I haven’t actually touched since December because I’ve been busy with http://blog.qt.io/blog/2015/03/31/qt-quick-controls-for-embedded/. Do/will the standard Qt models work with the native views? The example seen in the video is using a JS array as a model for the sake of simplicity, but the same set of models that Qt Quick supports (number, JS arrays, QObjectList, QAbstractItemModel, QQmlXxxModel...) is on the wish list. -- J-P Nurmi ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Allowing event delivery prior to and after QCoreApplication
On 2015-04-14 12:27, Thiago Macieira wrote: The problem is the public, *user* class if they derived from QApplication. If they've overridden notify(), then I need to know when the *user* class begins destruction so that we stop calling notify(). Would it be horrible to add a new method, e.g. shutdown(), which subclasses are required to call in their dtor? It won't fix existing applications, but it at least provides a mechanism to make things work. -- Matthew ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML bindings for native Android controls
On 14 Apr 2015, at 18:14, Jeremy Lainé jeremy.la...@m4x.org wrote: On 04/13/2015 03:46 PM, Nurmi J-P wrote: On 13 Apr 2015, at 14:50, Jeremy Lainé jeremy.la...@m4x.org wrote: How about just android-controls, which would become qt-android-controls if the project graduates from playground? I like this suggestion. In the end we will have much more (*) than just UI controls, though. Does that matter from the naming perspective? *) For example, good background service integration is important for my own use cases. Pretty much the same way WorkerScript works, I hope to be able to send arbitrary jsobjects between background services and UI instances. Another option is quick-android, which would become qt-quick-android”. I’d like to avoid the “quick word, because this is incompatible with Qt Quick. -- J-P Nurmi ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] QML bindings for native Android controls
On 04/13/2015 03:46 PM, Nurmi J-P wrote: On 13 Apr 2015, at 14:50, Jeremy Lainé jeremy.la...@m4x.org wrote: How about just android-controls, which would become qt-android-controls if the project graduates from playground? I like this suggestion. In the end we will have much more (*) than just UI controls, though. Does that matter from the naming perspective? *) For example, good background service integration is important for my own use cases. Pretty much the same way WorkerScript works, I hope to be able to send arbitrary jsobjects between background services and UI instances. Another option is quick-android, which would become qt-quick-android. Cheers, Jeremy ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Allowing event delivery prior to and after QCoreApplication
On Tuesday 14 April 2015 18:36:16 Robert Iakobashvili wrote: The problem here is that QCoreApplication is not reference counted and we can't change it without breaking *every* *single* *application*, since this is what people usually do: C++ idiom with protected destructor enforces heap-allocation of objects and prevents stack allocation. It requires some public destroy() calling delete this inside. Without breaking *every* *single* *application* -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Allowing event delivery prior to and after QCoreApplication
On Monday 13. April 2015 21.12.58 Thiago Macieira wrote: On Monday 13 April 2015 13:23:29 Thiago Macieira wrote: On Tuesday 13 January 2015 18:05:17 Thiago Macieira wrote: On Wednesday 14 January 2015 02:17:31 Olivier Goffart wrote: Finally, note what happens if there's a thread trying to deliver events *while* QCoreApplication is being shut down: notifyInternal() is probably dereferencing a dangling pointer. Good point. But one might argue that thread should be finished before the QCoreApplication is destroyed. Yeah, that sounds like the solution, but just look at both attempts to cause QProcessManager's thread to exit: https://codereview.qt-project.org/60586 https://codereview.qt-project.org/102526 For QtDBus, I could hook to QCoreApplication's destruction, close the connections, activate the pending replies with a Disconnected error, and stop the thread. I'd just rather not do it, if it weren't required. Hi everyone Albert has just told me that this is also hitting now KUniqueApplication with the new QtDBus changes. The reason is that the auxiliary thread isn't processing events before QCoreApplication is created, so no D-Bus calls complete. In fact, I'm pretty sure this causes the auxiliary thread to go on a busy-wait (100% CPU usage) because it registers socket notifiers that become readable, but never reads from them. I'd like some opinions on whether we should try this or not. Note another problem: if a thread is running and delivering events while the QCoreApplication gets destroyed, the application will have several race conditions: 1) data races accessing QCoreApplicationPrivate::is_app_closing 2) TOCTOU race in QCoreApplication::sendEvent for the existence of QCoreApplication So I have to ask: do we NEED to use QCoreApplication::notify() virtual outside the main thread? The documentation clearly says so, and therefore it is not entirely unlikely that somebody relies on that behavior :( (as much as I dislike it :) Would it be feasible to make event loops started before and after QCoreApplication truly independent from notify() but all the others join in? Simon ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Allowing event delivery prior to and after QCoreApplication
On Tuesday April 14 2015 07:28:03 Thiago Macieira wrote: On Tuesday 14 April 2015 09:46:09 René J.V. Bertin wrote: I don't know how to answer this since I have no idea what retain/release is and does. Can you explain? OK, sorry, I thought you had sufficient knowledge of ObjC programming (from before ARC made the whole retain/release mechanism largely transparent). Simplifying things a bit, ObjC uses a refcounting mechanism to keep track of whether objects are in use or not. It also uses allocation pools (NSAutoreleasePool) which contain the list of all objects allocated since they were created; these are created automatically when you enter a runloop for instance. Unused objects are deleted only when the pool is released (or drained), and it is at that time that their dealloc method is called. The effect is not unlike that of QObject::deleteLater(). I'm not sure exactly what happens with objects in the pool that are still in use; I presume the pool actually hangs around until all its elements have been released. There are some evident drawbacks to a scheme that discourages immediate deletion (and you're obliged to provide an NSAutoreleasePool in situations where they're not created for you) but it provides much better protection against things like pending events that get delivered after the destination object was deleted (cf. https://bugreports.qt.io/browse/QTBUG-44343). It's a pity ObjC is so intricately linked to OS X, because from a few quick attempts it seems to be perfectly possible to use an ObjC++ wrapper class to extend the retain/release scheme to C++ classes. Is this clear enough? R. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Allowing event delivery prior to and after QCoreApplication
On Tuesday 14 April 2015 16:56:19 René J.V. Bertin wrote:
[cut]
ObjC is so intricately linked to OS X, because from a few quick attempts it
seems to be perfectly possible to use an ObjC++ wrapper class to extend the
retain/release scheme to C++ classes.
Is this clear enough?
Yes, thank you.
C++ already has that, it's called reference counting. You may have heard we
use it in Qt :-)
The problem here is that QCoreApplication is not reference counted and we
can't change it without breaking *every* *single* *application*, since this is
what people usually do:
int main(int argc, char **argv)
{
SomeApplication app(argc, argv);
[rest of the application]
}
That stack declaration is the problem here. The app object will be destroyed
at the closing brace, whether we want it or not, and there's nothing we can do
to prevent it, delay it or even hook something as it begins.
We can only catch it half-way through, when the destruction has reached one of
our classes (~QApplication, ~QGuiApplication or ~QCoreApplication), by which
time the virtual table has already changed and it's too late.
--
Thiago Macieira - thiago.macieira (AT) intel.com
Software Architect - Intel Open Source Technology Center
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Allowing event delivery prior to and after QCoreApplication
On Tue, Apr 14, 2015 at 6:27 PM, Thiago Macieira
thiago.macie...@intel.com wrote:
On Tuesday 14 April 2015 16:56:19 René J.V. Bertin wrote:
[cut]
ObjC is so intricately linked to OS X, because from a few quick attempts it
seems to be perfectly possible to use an ObjC++ wrapper class to extend the
retain/release scheme to C++ classes.
Is this clear enough?
Yes, thank you.
C++ already has that, it's called reference counting. You may have heard we
use it in Qt :-)
The problem here is that QCoreApplication is not reference counted and we
can't change it without breaking *every* *single* *application*, since this is
what people usually do:
int main(int argc, char **argv)
{
SomeApplication app(argc, argv);
[rest of the application]
}
That stack declaration is the problem here. The app object will be destroyed
at the closing brace, whether we want it or not, and there's nothing we can do
to prevent it, delay it or even hook something as it begins.
We can only catch it half-way through, when the destruction has reached one of
our classes (~QApplication, ~QGuiApplication or ~QCoreApplication), by which
time the virtual table has already changed and it's too late.
C++ idiom with protected destructor
enforces heap-allocation of objects and prevents stack allocation.
It requires some public destroy() calling delete this inside.
jm2c
Regards,
Robert
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Allowing event delivery prior to and after QCoreApplication
On Tuesday 14 April 2015 09:46:09 René J.V. Bertin wrote: On Monday April 13 2015 21:12:58 Thiago Macieira wrote: Hello, I'd like some opinions on whether we should try this or not. Note another problem: if a thread is running and delivering events while the QCoreApplication gets destroyed, the application will have several race conditions: 1) data races accessing QCoreApplicationPrivate::is_app_closing 2) TOCTOU race in QCoreApplication::sendEvent for the existence of QCoreApplication So I have to ask: do we NEED to use QCoreApplication::notify() virtual outside the main thread? Not that I have any intimate knowledge of the inner workings you're discussing, but this sounds like the kind of situation ObjC avoids with its retain/release scheme. Would it help if you somehow imposed such a scheme on central classes like QCoreApplication? I don't know how to answer this since I have no idea what retain/release is and does. Can you explain? -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] [Interest] QJSEngine and error line
On 9 April 2015 at 19:17, Simon Hausmann
simon.hausm...@theqtcompany.com wrote:
On Thursday 9. April 2015 11.52.31 Simon Hausmann wrote:
On Wednesday 8. April 2015 23.45.29 Sze Howe Koh wrote:
[...]
Going off on a slight tangent:
https://doc.qt.io/qt-5/qjsvalue.html#toVariant says that an Object is
converted to a QVariantMap. Each property is converted to a QVariant,
recursively. However, calling toVariant() on an Error object
(isError() == isObject() == true) produces an empty QVariantMap event
though QJSValueIterator gets the properties just fine (using Qt
5.4.1). Is this expected?
That could be a bug. You should see the enumerable properties, which I think
include message and name. If a strack trace was producible at constructor
time, then you should also see the fileName and lineNumber properties.
stack however will not be visible.
Ah, I had another look and I have to correct myself here:
The properties in question (message, name, etc.) are defined as being non-
enumerable [1], which is why the are not visible in the toVariant()
conversion. Similarly those properties are not visible if you do
for (propName in error) {
console.log(propName)
}
QJSValueIterator - as a C++ tool - lists _all_ properties of an object, even
the non-enumerable ones.
Thanks for looking it up.
Was it a conscious decision to restrict QJSValue::toVariant() to
enumerable properties only? What's the rationale?
Simon
[1] Although those properties are technically vendor extensions and non-
standard, they are commonly implemented across web browser oriented JavaScript
engines and _there_ they are non-enumerable.
name and message are standard :)
http://www.ecma-international.org/ecma-262/5.1/#sec-15.11.4
If I've read the spec correctly, all properties of the Error prototype
should be non-enumerable, so I think Qt is compliant with this part of
the spec.
Regards,
Sze-Howe
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Allowing event delivery prior to and after QCoreApplication
On Tuesday April 14 2015 09:27:34 Thiago Macieira wrote: On Tuesday 14 April 2015 17:53:20 René J.V. Bertin wrote: This may be an open door, but couldn't you change the application's entry point (or provide an alternative entry point like KDE does with kdemain). That gives you an extra layer around what the user sees as the main function. I don't see how that is beneficial to anything here. It's at best a no-op. Having a layer above the user main should give you more manoeuvring room to perform house keeping tasks. Whether that's of use here is a different question. It does seem though that it would allow you to stop calling notify() once the user main has returned. That won't catch cases where the Q*Application instance is deleted before main returns, but maybe those cases are less frequent. The problem is not the d pointer or the private class. Wasn't saying it was. Same answer as I gave to Julien: if we can't force applications to call it, they won't and we can't rely on it being used. And if we do, it's source- incompatible. Between a rock and a hard place one could opt for a compromise. You're planning to introduce changes to QtDBus that may break things. Applications that don't break because of it don't need a solution. If those that break can be fixed with a simple invocation of a new mechanism provided exactly for that purpose, isn't that good enough? R ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Allowing event delivery prior to and after QCoreApplication
On Tuesday 14 April 2015 14:37:25 Matthew Woehlke wrote: Would it be horrible to add a new method, e.g. shutdown(), which subclasses are required to call in their dtor? It won't fix existing applications, but it at least provides a mechanism to make things work. Same answer as I gave to Julien: if we can't force applications to call it, they won't and we can't rely on it being used. And if we do, it's source- incompatible. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Allowing event delivery prior to and after QCoreApplication
On Tuesday 14 April 2015 21:26:40 René J.V. Bertin wrote: Between a rock and a hard place one could opt for a compromise. You're planning to introduce changes to QtDBus that may break things. Applications that don't break because of it don't need a solution. If those that break can be fixed with a simple invocation of a new mechanism provided exactly for that purpose, isn't that good enough? Those applications are broken already today, since we use threads for OpenGL, for the QPA event management and, up to Qt 5.4, in QProcess. They may not have noticed they're broken, but they're broken. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Allowing event delivery prior to and after QCoreApplication
On Tuesday April 14 2015 15:58:20 Thiago Macieira wrote: They may not have noticed they're broken, but they're broken. Ok then If those that break can be fixed with a simple invocation of a new mechanism provided exactly ^ shatter into pieces for that purpose, isn't that good enough? T,FTFY :) ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Allowing event delivery prior to and after QCoreApplication
On Tuesday 14 April 2015 19:55:47 Julien Cugnière wrote: 2015-04-14 16:36 GMT+02:00 Thiago Macieira thiago.macie...@intel.com: 2) fix it by not passing through notify() outside the main thread. That's the solution I implemented in I27eaacb532114dd188c413d4ad2a4bb443e6. People rely on QCoreApplication::notify to provide a try/catch when working with Qt and exceptions. That solution has been disproven. It is neither sufficient nor necessary for proper exception unwinding of the event loop. It hasn't been for a long time, since at least around Qt 4.4, probably more. That allows dealing with them in a single place, rather than in every single function called by a Qt event. If it stops working in threads, some applications will definitely see the difference. They won't necessarily break, as I seem to remember Qt has a generic try/catch around notify, but they will loose any information from the exception. We removed the try/catch and replaced with stack objects that will unwind properly. If you're lucky, an exception will simply unwind QCoreApplication out of exec(), so a try/catch around exec() may work. But this is untested and unsupported. DO NOT throw through the event loop and DO NOT throw back to the signal-slot delivery mechanism. We will not deal with bug reports that this does not work. I may accept patches that fix this, provided they don't introduce performance issues. So I am not considering this a valid use-case for the problem at hand. Is it that common to destroy the application object will threads are still delivering events ? It feels weird to me... It would be a shame to fix a uncommon case by breaking a common one. Yes, it happens and that is what's happening with the QtDBus changes I'm making: the thread continues running after QCoreApplication exits. The previous QProcessManager solution tried to exit the thread during QCoreApplication shutdown, but note that it was already too late! The routines added with qAddPostRoutine are run from the QCoreApplication destructor, so the vtables have already changed and we've already run into undefined behaviour. The lastWindowClosed() and aboutToQuit() signals are also too early: they are emitted shortly before exec() returns, but the application may continue running after that. Just thinking out loud, but assuming it isn't that common, would it make sense to provide a setting to choose between the two behaviors ? Not an applicaation-wide setting because you don't know *which* threads are running in the background. But I could make it a per-thread choice. Or a Qt function/slot one need to explicitly call from the most derived application destructor when needing to continue processing events ? Source-compatible, but requires changes to all applications, so we can't rely on applications having been corrected to deal with this. So it's useless: we can't rely on the feature. Or provide a different way of creating/destroying the application object when this behavior is required ? Same thing: providing a different way without breaking source compatibility means we can't rely on it being used. -- Thiago Macieira - thiago.macieira (AT) intel.com Software Architect - Intel Open Source Technology Center ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
