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

List:       kde-devel
Subject:    Re: Threadweaver job won't die, it remains
From:       Harald Hvaal <haraldhv () stud ! ntnu ! no>
Date:       2008-10-12 17:23:52
Message-ID: 200810130223.52515.haraldhv () stud ! ntnu ! no
[Download RAW message or body]

On Sunday 12 October 2008 04:25:43 Cyrille Berger wrote:
> Hi,
>
> sounds like you have a race condition. Are you trying to access the same
> threadweaver from two different threads ? In which case I am not sure that
> it is supported.
Not sure what you mean by "accessing the threadweaver", but if you mean 
queueing the job, then no, this is all done in the same thread, like this:

void Job::start()
	{
		ThreadExecution *thread = new ThreadExecution(this);
		ThreadWeaver::Weaver::instance()->enqueue( thread );
	}

The actual ThreadWeaver job looks like this:

	void ThreadExecution::run()
	{
		//perform the work in this thread!
		m_job->doWork();
		setFinished(true);
		emit done(this);
		kDebug( 1601 ) << "Finished dowork";
	}

And doWork is an implemented method performing the work of the subclassed 
KJob, and calling KJob::emitResult() when done there. An example from the 
AddJob class:

	void AddJob::doWork()
	{
		emit description( this, i18np( "Adding a file", "Adding %1 files", 
m_files.count() ) );

		ReadWriteArchiveInterface *m_writeInterface =
			qobject_cast<ReadWriteArchiveInterface*>
			(m_interface);

		Q_ASSERT(m_writeInterface);
		
		m_writeInterface->registerObserver( this );
		setError( !m_writeInterface->addFiles( m_files, m_options ) );
		m_writeInterface->removeObserver( this );

		emitResult();

	}

Does this look like the race condition you mentioned in your previous email?

-- 
Harald Hvaal
haraldhv@stud.ntnu.no

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
[prev in list] [next in list] [prev in thread] [next in thread]