[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-commits
Subject:    Re: branches/work/kviewshell-0.7/kviewshell/plugins [POSSIBLY UNSAFE]
From:       Wilfried Huss <Wilfried.Huss () gmx ! at>
Date:       2006-05-28 19:58:02
Message-ID: 200605282202.47397.Wilfried.Huss () gmx ! at
[Download RAW message or body]

Am Sonntag, 28. Mai 2006 16:16 schrieb Thiago Macieira:
> Wilfried Huss wrote:
> >Am Sonntag, 28. Mai 2006 11:49 schrieb Thiago Macieira:
> >> Wilfried Huss wrote:
> >> >One sometimes gets a "Xlib: unexpected async reply (sequence
> >> > 0x8c56)!" message, and then the GUI freezes. This doesn't happen in
> >> > trunk with Qt4/KDE4.
> >>
> >> This means you're doing GUI stuff from outside the GUI thread.
> >
> >Yes I know, I just don't know where I do GUI stuff.
> >
> >Does KProcIO make some xlib calls? Because other that that I only use
> >QImage, QByteArray, KTempFile, QString, QStringList, QFile, QFileInfo
> >and QDataStream.
> 
> KProcIO uses QSocketNotifiers (inside KProcess), so you're not allowed to 
> use it non-GUI threads.

It would be nice if such things were mentioned somewhere in the docs.
 
> Depending on your KDE version, KProcess also calls QApplication::flushX(). 
> I removed that call in KDE 3.5.3 and 4.0.

So this means using only the Qt3/KDE3-APIs I cannot start a process outside
the main thread? Is this right?

The Qt4 docs say that QProcess is reentrant, so this should work there.

> >> Remember that you are not allowed to use QObject objects outside the
> >> GUI thread either in Qt 3!
> >
> >Why? From the Qt3 docs: "The QObject class itself is reentrant. However,
> > certain rules apply when creating and using QObjects in a thread that
> > is not the GUI thread."
> >
> >Or: "The Signals and Slots mechanism can be used in separate threads,
> > ...".
> 
> Signals are delivered on the thread they are emitted. But the signal-slot 
> connection list is not protected by mutex in Qt3, so you're not allowed 
> to call QObject::connect or emit a signal unless you've locked the entire 
> program yourself.

Ok.

Thanks,
Wilfried.
[prev in list] [next in list] [prev in thread] [next in thread]