On Saturday, 5 October 2019 06:13:56 PDT Richard Weickelt wrote:
> >> Because I attached a debugger and stopped T1 during
> >> QCoreApplication::processEvents(). I can see E3 (the one that the thread
> >> is
> >> currently processing) in postEventList at index 0 and E2 at index 1.
> >> That's
> >>
>> Because I attached a debugger and stopped T1 during
>> QCoreApplication::processEvents(). I can see E3 (the one that the thread is
>> currently processing) in postEventList at index 0 and E2 at index 1. That's
>> it. From there I see the following call chain
>> QEventDispatcherGlib::processEven
30.09.2019, 11:38, "Rainer Wiesenfarth" :
> 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 would strongly oppose such deprecation, as
On Monday, 30 September 2019 08:05:23 PDT Ola Røer Thorsen wrote:
> man. 30. sep. 2019 kl. 16:48 skrev Thiago Macieira <
>
> thiago.macie...@intel.com>:
> > It's just wrong to use it. Just like QThread::{,m,u}sleep. Don't use them.
>
> What's wrong with the sleep functions in particular? Are they
On Monday, 30 September 2019 09:35:48 PDT Uwe Rathmann wrote:
> On 9/30/19 4:43 PM, Thiago Macieira wrote:
> > It's not advisable to use nested event loops.
>
> It is not the first time that you gave this warning, but something like
> QDialog::exec is simply too handy for GUI development.
Which i
On 9/30/19 4:43 PM, Thiago Macieira wrote:
It's not advisable to use nested event loops.
It is not the first time that you gave this warning, but something like
QDialog::exec is simply too handy for GUI development.
Of course there are known side effects, but IMHO it should be the job of
a
On Mon, Sep 30, 2019 at 6:07 PM Ola Røer Thorsen wrote:
> What's wrong with the sleep functions in particular?
>
They're uninterruptible. In 99.9(9)% of cases there's a better way to
suspend a thread for some time than unconditionally putting it to sleep.
> Are they worse than calling for exam
man. 30. sep. 2019 kl. 16:48 skrev Thiago Macieira <
thiago.macie...@intel.com>:
>
> It's just wrong to use it. Just like QThread::{,m,u}sleep. Don't use them.
>
>
What's wrong with the sleep functions in particular? Are they worse than
calling for example unistd.h's "usleep" or
"std::this_thread:
On Monday, 30 September 2019 01:34:25 PDT Rainer Wiesenfarth 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?
It's not obsolete. It's not broken.
It's just wrong to use it. Just like QThre
On Monday, 30 September 2019 01:33:12 PDT Richard Weickelt wrote:
> Because I attached a debugger and stopped T1 during
> QCoreApplication::processEvents(). I can see E3 (the one that the thread is
> currently processing) in postEventList at index 0 and E2 at index 1. That's
> it. From there I see
On 9/30/19 3:51 AM, Rainer Wiesenfarth wrote:
...which would be a perfect reason to at least mark it as obsolete in Qt 6?
It cannot be obsoleted because there is too much bad code out there
relying on it. Bad examples doing database I/O and serial I/O within the
main event loop, etc.
I stron
>> - 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 3
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 th
>> - Thread T1 is handling an event E1
>> - Thread T1 sends E3 to itself (queued connection)
>> - Thread T2 sends an event E2 to T1 (queued connection)
>> - Thread T1 handles E3 after completing E1.
>> - Thread T1 while handling E3 calls QCoreApplication::processEvents()
>> periodically
>> - E2 is
On Sunday, 29 September 2019 22:51:57 PDT Richard Weickelt wrote:
> After debugging a bit, I come to realize that my above description is
> incorrect.
>
> - Thread T1 is handling an event E1
> - Thread T1 sends E3 to itself (queued connection)
> - Thread T2 sends an event E2 to T1 (queued connecti
>> what is the expected event execution order in the following scenario?
>>
>> - 2 Threads running their event loop
>> - Thread T1 is handling an event E1
>> - Thread T2 sends an event E2 to T1 (queued)
>> - Thread T1 (still handling E1) emits an event E3 to itself (direct) after
>> E2 has already
On Sunday, 29 September 2019 02:49:36 PDT Richard Weickelt wrote:
> Hello,
>
> what is the expected event execution order in the following scenario?
>
> - 2 Threads running their event loop
> - Thread T1 is handling an event E1
> - Thread T2 sends an event E2 to T1 (queued)
> - Thread T1 (still h
On 9/29/19 5:00 AM, Richard Weickelt wrote:
what is the expected event execution order in the following scenario?
- 2 Threads running their event loop
- Thread T1 is handling an event E1
- Thread T2 sends an event E2 to T1 (queued)
- Thread T1 (still handling E1) emits an event E3 to itself (di
Hello,
what is the expected event execution order in the following scenario?
- 2 Threads running their event loop
- Thread T1 is handling an event E1
- Thread T2 sends an event E2 to T1 (queued)
- Thread T1 (still handling E1) emits an event E3 to itself (direct) after
E2 has already been enqueue
19 matches
Mail list logo
