[Interest] interobject communication model and control flow
Hi. I am in the middle of refactoring a library, which I am going to publish open source. I found mysefl stuck reconsidering API in terms of interobject communication. There is a central class that have several signals, and I try to imagine what library user could do in corresponding slots: Should deleting an instance be possible from directly connected slot? What should happen if one reenters event loop in a directly connected slot? Should processing continue or lock? In general, API is asynchronous in sense that methods just set some target state and use queued connection to do processing from event loop and signals just mark some events. Qt itself has nice documentation that, for example, flags some method to be reentrant or thead safe. But synchronous or asynchronous, event loop reentry or deletion behavior is rarely described in detailed section. So I struggle to find a reference implementation. I wonder: Does anyone consider these problems designing or using APIs? Do you expect an object to continue processing even if control flow was taken into event loop via direct signal slot connection? What is the correct term or category to define event loop reentry safety? Will appreciate any comments. Wishes. https://doc.qt.io/qt-5/signalsandslots.html https://doc.qt.io/qt-5/threads-reentrancy.html https://doc.qt.io/qt-5/qiodevice.html#bytesWritten https://doc.qt.io/qt-5/qthread.html#finished https://wiki.qt.io/API_Design_Principles https://github.com/qt/qtbase/blob/5.12/src/corelib/thread/qthread_win.cpp#L403 https://github.com/qt/qtbase/blob/5.12/src/corelib/thread/qthread_unix.cpp#L400 ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Expected event execution order in this multi-thread application
>> - E2 is sitting in the event queue of T1 at the second position but gets >> never executed. Use combination of QCoreApplication::sendPostedEvents(); QCoreApplication::processEvents(); . пн, 30 сент. 2019 г. в 11:37, Rainer Wiesenfarth < rainer_wiesenfa...@trimble.com>: > On Mon, Sep 30, 2019 at 9:26 AM Thiago Macieira > wrote: > >> [...] Anyway, this is when you should use processEvents(): never. >> > > ...which would be a perfect reason to at least mark it as obsolete in Qt 6? > > I strongly second Thiago's recommendation: processEvents() usually > introduces more problems than it solves. > > -- > Software Engineer | Trimble Imaging Division > Rotebühlstraße 81 | 70178 Stuttgart | Germany > Office +49 711 22881 0 | Fax +49 711 22881 11 > http://www.trimble.com/imaging/ | http://www.inpho.de/ > > Trimble Germany GmbH, Am Prime Parc 11, 65479 Raunheim > Eingetragen beim Amtsgericht Darmstadt unter HRB 83893, > Geschäftsführer: Dr. Frank Heimberg, Jürgen Kesper > ___ > Interest mailing list > Interest@qt-project.org > https://lists.qt-project.org/listinfo/interest > ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
