[Development] Allowing event delivery prior to and after QCoreApplication

[Knoll Lars]

On 15/04/15 11:30, "Simon Hausmann" <simon.hausmann at theqtcompany.com>
wrote:

>On Tuesday 14. April 2015 07.36.49 Thiago Macieira wrote:
>> 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 I27eaacb532114dd188c4ffff13d4ad2a4bb443e6.
>> 
>> 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
>
>I understand that you're not introducing a new race condition, but we
>also 
>have to consider that option number 2 results in the removal of a feature
>that 
>is documented and has been there for a long time and that works in the
>common 
>case. The common case I'm thinking of is that an application starts up,
>after 
>some time it starts one or multiple working threads, then those threads
>terminate and maybe at some point later the application also terminates.
>That case works just fine and my concern is that there are people out
>there 
>using this feature.
>
>
>That said, I personally think the feature of having this ultra-central
>hook 
>that is called from all (Qt) threads is a bad feature to have. If we were
>discussing the introduction of it, I would probably attempt to argue
>against 
>it.
>
>However now we are discussing the removal of it, and I think we need more
>insight on that before going ahead.

Well, I’d say we should try to see how much this is being used. I don’t
think we ourselves use it at all. How much is this used in other projects?

The central notify() hook is something I don’t like at all. It’s very easy
to mess things up using it, and I would think most people reimplementing
notify() need it for the main thread only.

So I would rather go with approach 2, document this as a change, and then
try to offer a replacement so people can filter and inspect events on
threads.

Cheers,
Lars