Review Request: Quit Eventloop before emitting finished and result signals

[Michael Pyne]

> On 2009-11-11 23:29:01, Andreas Pakulat wrote:
> > I might be missing something, but why would one call KJob::exec() twice on the same job? I thought thats already an error to do, much like you don't run the same qthread instance twice.

Well it certainly may be a bad job to call KJob::exec() twice but at the same time at the library level it's certainly best to protect against it if it's easily done.  This patch just ensures that there's a strict rather than an undefined ordering between emitting result() to user programs and stopping the event loop, so it seems to me better even if there's no specific breakage yet.


- Michael


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://reviewboard.kde.org/r/2140/#review3044
-----------------------------------------------------------


On 2009-11-11 22:06:41, Sebastian Sauer wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://reviewboard.kde.org/r/2140/
> -----------------------------------------------------------
> 
> (Updated 2009-11-11 22:06:41)
> 
> 
> Review request for kdelibs.
> 
> 
> Summary
> -------
> 
> If KJob::exec is called then it can happen that the result(KJob*) signal is emitted before the QEventLoop in KJob::exec is quit. If a slot connected with the result(KJob*) signal does then e.g. call the same KJob::exec again then funny things may happen. The patch introduces a new internal signal that is called before the finished and result signals are emitted and that quits the eventloop. This way we can be sure that the finished and result signals are always emitted once the eventloop is done.
> 
> 
> Diffs
> -----
> 
>   /trunk/KDE/kdelibs/kdecore/jobs/kjob.h 1047234 
>   /trunk/KDE/kdelibs/kdecore/jobs/kjob.cpp 1047234 
> 
> Diff: http://reviewboard.kde.org/r/2140/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Sebastian
> 
>