[Development] Allowing event delivery prior to and after QCoreApplication
Knoll Lars
Lars.Knoll at theqtcompany.com
Wed Apr 15 11:39:59 CEST 2015
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
More information about the Development
mailing list