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

List:       kde-devel
Subject:    Re: KAuth helper trouble
From:       Michael Pyne <mpyne () kde ! org>
Date:       2018-04-27 3:13:43
Message-ID: 20180427031343.GA7917 () midna
[Download RAW message or body]

On Wed, Apr 25, 2018 at 07:33:25PM +0000, Amber Schenck wrote:
> Hi kde-devel,
> 
> I'm trying to convert my package manager frontend to KAuth so it
> doesn't have to be run under kdesu but my helper doesn't seem to be
> behaving and I'm having trouble debugging it.  The helper code right
> now is: ActionReply KurooHelper::sync( const QVariantMap& args )
> {
> 	connect(syncProc, &KProcess::readyReadStandardOutput, this, &KurooHelper::slotEmergeOutput);
> 	syncProc->start();

You have a signal/slot connection here, which will require returning
into the Qt event loop at some point to actually work.

> 	syncProc->waitForStarted( 5000 );

This works even without an event loop according to Qt, but this only
waits for the process to start, it doesn't wait for output to be
available, or the process to finish.

> 	qDebug() << "Started sync";
> 	while ( QProcess::Running == syncProc->state() || QProcess:Starting == syncProc->state() ) {
> 		if ( HelperSupport::isStopped() ) {
> 			qDebug() << "Sync cancelled by user";
> 			syncProc->kill();
> 			return ActionReply::UserCancelledReply();
> 		}
> 		sleep( 10 );
> 		qDebug() << "Sync tick";
> 	}

Throughout this whole loop, the code never returns to Qt, which means
the Qt event loop can't actually call the slotEmergeOutput signal.  I
think you intend for sleep( 10 ) to allow this to happen behind the
scenes, but this is more of a "cooperative multitasking" model -- the
code needs to be organized such that it returns to the event loop like
normal, or it can manually run the event loop (such as using
QApplication::processEvents or a local QEventLoop, though neither are
recommended), or use a function which doesn't require an event loop like
QProcess::waitForFinished.

> This call is expected to be long-running, hence the ugly while () in
> there, but it never returns any output and doesn't take as long as it
> should.  Is there any way I can get better debugging output to see
> what is happening?

qDebug() should work OK but tools like GammaRay might make it easier to
trace between signal/slot emissions (once the missing event loop is
fixed, that is).

Regards,
 - Michael Pyne
[prev in list] [next in list] [prev in thread] [next in thread]