Qt-interest Archive, December 2006
Threads, signals etc.
Pages: Prev | 1 | 2 | Next
Message 16 in thread
On Monday 18 December 2006 10:49, Bradley T Hughes wrote:
> > the API user does know when the "moveToThread()" method gets called (in
> > exact the moment it gets called :) If the object had to handle the event
> > it cannot know th exact time of invocation, but only guess.
>
> The event is sent at the end of moveToThread(), so you know that if you get
> a ThreadChange event, moveToThread() has just finished what it needs to do
> and is about to return.
Oops, I lied. The event is sent before moveToThread() does its job.
--
[ signature omitted ]
Message 17 in thread
Bradley T Hughes wrote:
> On Friday 15 December 2006 21:15, Enrico Thierbach wrote:
>> While these two concepts do often come in pairs they are not identical.
>> For example an object could be part of two different hierarchies:
>> obviously in such a case ownership cannot be taken by one or the other
>> hierarchy, but must handled externally.
>
> From a theoretical point of view, yes, having a single object in multiple
> hierarchies is possible, but not in Qt :)
You make it sound like an esoteric idea. In fact, it is not - and you
can see it even in Qt4: what else are the items filtered by a
QSortFilterProxyModel but the same items as in the underlying item model
yet in a different "container"?
>
>> [thread affinity issue]
>
> I don't see the problem. If you don't like the default affinity, change it.
> This is what QObject::moveToThread() is for...
Yes. And this is why I would prefer moveToThread() virtual.
> The event is sent at the end of moveToThread(), so you know that if
> you get a ThreadChange event, moveToThread() has just finished what
it > needs to do and is about to return.
&
> Oops, I lied. The event is sent before moveToThread() does its job.
See, this is why I prefer moveToThread() virtual.
>
>> I hope with "Keeping the whole Qt 5..." you don't mean Qt5 to be
>> ABI-compatible with Qt4? And hopefully something can be done towards Qt
>> 5. Another argument supporting my stance may be on the time of invocation:
>
> I'm not talking about keeping Qt 5 ABI compatible with Qt 4; I'm talking about
> Qt 5.x being compatible with 5.y.
Sounded different originally. But great: so there is chance of getting
some API changes in Qt5. Cool, if they only go in the right direction ;-)
>>>> Couldn't QThread expose its internal event loop via some method?
>> I missed the answer to that?
>
> Our standard answer: private impementation (P-IMPL). We don't expose the
> internals of Qt :)
>
Fair enought. However, QCoreApplication exposes
bool processEvents(ProcessEventsFlags flags = AllEvents)
while QThread does not. Any reason why?
/eno
--
[ signature omitted ]
Message 18 in thread
On Monday 18 December 2006 13:18, Enrico Thierbach wrote:
> Bradley T Hughes wrote:
> > From a theoretical point of view, yes, having a single object in multiple
> > hierarchies is possible, but not in Qt :)
>
> You make it sound like an esoteric idea. In fact, it is not - and you
> can see it even in Qt4: what else are the items filtered by a
> QSortFilterProxyModel but the same items as in the underlying item model
> yet in a different "container"?
Are we talking about QObjects or not?
> >> [thread affinity issue]
> >
> > I don't see the problem. If you don't like the default affinity, change
> > it. This is what QObject::moveToThread() is for...
>
> Yes. And this is why I would prefer moveToThread() virtual.
>
> > The event is sent at the end of moveToThread(), so you know that if
> > you get a ThreadChange event, moveToThread() has just finished what
>
> it > needs to do and is about to return.
>
> &
>
> > Oops, I lied. The event is sent before moveToThread() does its job.
>
> See, this is why I prefer moveToThread() virtual.
Because I misread the code...? :)
> >> I hope with "Keeping the whole Qt 5..." you don't mean Qt5 to be
> >> ABI-compatible with Qt4? And hopefully something can be done towards Qt
> >> 5. Another argument supporting my stance may be on the time of
> >> invocation:
> >
> > I'm not talking about keeping Qt 5 ABI compatible with Qt 4; I'm talking
> > about Qt 5.x being compatible with 5.y.
>
> Sounded different originally. But great: so there is chance of getting
> some API changes in Qt5. Cool, if they only go in the right direction ;-)
I think we're misunderstanding each other. I am saying the techniques we use
to guarantee binary compatibility will still be used in Qt 5. The API of Qt
is constantly evolving, and you don't have to wait for Qt 5 for it.
> >>>> Couldn't QThread expose its internal event loop via some method?
> >>
> >> I missed the answer to that?
> >
> > Our standard answer: private impementation (P-IMPL). We don't expose the
> > internals of Qt :)
>
> Fair enought. However, QCoreApplication exposes
> bool processEvents(ProcessEventsFlags flags = AllEvents)
> while QThread does not. Any reason why?
Because there's no reason for QThread to duplicate code already in
QCoreApplication. The docs should be more explicit about this, but calling
QCoreApplication::processEvents() will process events for the current thread.
Another option is to create a QEventLoop object and just call processEvents()
on it.
--
[ signature omitted ]
Message 19 in thread
(Moved back to qt-interest)
On Monday 18 December 2006 16:48, Enrico Thierbach wrote:
> Hi Brad,
>
> >> See, this is why I prefer moveToThread() virtual.
> >
> > Because I misread the code...? :)
>
> Because the question wouldn't arise in the first place. In a derived
> class MyObject I could decide what to do when moveToThread gets called
> and if to do it before, after, or before and after
> QObject::moveToThread() gets called, because it is me (well, not me
> literally, but my code :) which invokes the base classes method.
Making a function virtual just to make it virtual is something we avoid doing.
If you can come up with some convincing reasons on how and why the current
mechanism doesn't work, feel free to send them to qt-bugs or through the
feedback form on the web.
> Anyway, we are sailing murky water meanwhile...
>
> any chance there will be a more or less formal process in which the
> community may discuss aspects of the Qt5 API.
Qt 5 is a long, long ways away. We're not even thinking about Qt 5 at
Trolltech yet. There's not point in starting these kinds of discussions now.
--
[ signature omitted ]
