BlockingKProcess should be fixed.

Hi.

As in my recent posts named
"SVNFileInfoProvider::status",
BlockingKProcess and KIO::NetAccess::synchronousRun()
conflicts each other. This conflict happens because each
class
use the same qApp->enter_loop(), exit_loop().

1. Reasons of conflict.

When CppSupportPart opens it runs
BlockingKProc::enter_loop()
And the stackframe piles over that. At some point,
synchronousRun()
is called on top of the stackframe.
synchronousRun() also calls enter_loop(), and the looplevel
becomes three.

At this point child process of BlockingProc finishes and
exit_loop()
is called by the slot. This exit_loop() causes
synchronousRun()
return, and the BlockingProc has no way but to wait
timeout.

2. Suggestions.

It would be good if the blocking mechanism can be
implemented
by different method. But if this is hard, the
BlockingKProc's timeout
should be more short, because BKProc should wait 60 seconds
to exit the loop, when NetAccess::syncRun() and BKProc
conflicts,

The timeout can be lowered by 3~4 seconds, since the
processes
used by KDev is simple ones like "gcc -v
nullfile.cpp"

Any opinions??

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Sunday 22 April 2007, dukju ahn wrote:
> Hi.
>
> As in my recent posts named
"SVNFileInfoProvider::status",
> BlockingKProcess and KIO::NetAccess::synchronousRun()
> conflicts each other. This conflict happens because
each class
> use the same qApp->enter_loop(), exit_loop().
>
> 1. Reasons of conflict.
>
> When CppSupportPart opens it runs
BlockingKProc::enter_loop()
> And the stackframe piles over that. At some point,
synchronousRun()
> is called on top of the stackframe.
> synchronousRun() also calls enter_loop(), and the
looplevel
> becomes three.
>
> At this point child process of BlockingProc finishes
and exit_loop()
> is called by the slot. This exit_loop() causes
synchronousRun()
> return, and the BlockingProc has no way but to wait
timeout.
>
> 2. Suggestions.
>
> It would be good if the blocking mechanism can be
implemented
> by different method. But if this is hard, the
BlockingKProc's timeout
> should be more short, because BKProc should wait 60
seconds
> to exit the loop, when NetAccess::syncRun() and BKProc
conflicts,
>
> The timeout can be lowered by 3~4 seconds, since the
processes
> used by KDev is simple ones like "gcc -v
nullfile.cpp"
>
> Any opinions??

BlockingKProcess uses the very same method as NetAccess (the
idea was 
copied from there). The question is *how* can synchronousRun
be called 
while the BlockingKProcess runs a second event loop. This is
the 
problem that should be solved, as otherwise running 
KIO::NetAccess::stat (for example) instead of a
BlockingKProcess 
doesn't really make a difference.

Andras


-- 
Quanta Plus developer - http://quanta.kdewebdev.o
rg
K Desktop Environment - http://www.kde.org

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 22.04.07 15:44:32, dukju ahn wrote:
> 2. Suggestions.
> 
> It would be good if the blocking mechanism can be
implemented
> by different method. But if this is hard,

I doubt its possible at all, else somebody would've
implemented it for
KIO.

> the BlockingKProc's timeout should be more short,
because BKProc
> should wait 60 seconds to exit the loop, when
NetAccess::syncRun() and
> BKProc conflicts,
>
> The timeout can be lowered by 3~4 seconds, since the
processes
> used by KDev is simple ones like "gcc -v
nullfile.cpp"
 
Not all of these cases are that short, for example in QMake
Manager it
reads a lot of data from the qmake call which can take quiet
some time
on slower machines.

Andreas

-- 
You will gain money by a speculation or lottery.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Sunday 22 April 2007 22:47:12 Andreas Pakulat wrote:
> Not all of these cases are that short, for example in
QMake Manager it
> reads a lot of data from the qmake call which can take
quiet some time
> on slower machines.
>
> Andreas

The same for include-path resolution, where things like
"make -W myfile.cpp -n 
myfile.o" are called.

greetings, David

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

2007/4/23, Andras Mantia <amantiakde.org>:
> On Sunday 22 April 2007, dukju ahn wrote:
> > As in my recent posts named
"SVNFileInfoProvider::status",
> > BlockingKProcess and
KIO::NetAccess::synchronousRun()
> > conflicts each other. This conflict happens
because each class
> > use the same qApp->enter_loop(), exit_loop().
> >
> > 1. Reasons of conflict.
> >
> > When CppSupportPart opens it runs
BlockingKProc::enter_loop()
> > And the stackframe piles over that. At some point,
synchronousRun()
> > is called on top of the stackframe.
> > synchronousRun() also calls enter_loop(), and the
looplevel
> > becomes three.
> >
> > At this point child process of BlockingProc
finishes and exit_loop()
> > is called by the slot. This exit_loop() causes
synchronousRun()
> > return, and the BlockingProc has no way but to
wait timeout.
> >
> > 2. Suggestions.
> >
> > It would be good if the blocking mechanism can be
implemented
> > by different method. But if this is hard, the
BlockingKProc's timeout
> > should be more short, because BKProc should wait
60 seconds
> > to exit the loop, when NetAccess::syncRun() and
BKProc conflicts,
> >
> > The timeout can be lowered by 3~4 seconds, since
the processes
> > used by KDev is simple ones like "gcc -v
nullfile.cpp"
> >
> > Any opinions??
>
> BlockingKProcess uses the very same method as NetAccess
(the idea was
> copied from there). The question is *how* can
synchronousRun be called
> while the BlockingKProcess runs a second event loop.

In a BKProc's second loop, events in event queue are
dispatched one by one.
Among these, there is some event that emits signals and
subsequent slots.
It is that slot that invokes function calls which contains
synchronousRun()

Anyway, this problem is now removed as we don't use function
calls
that uses synchronousRun(). So don't worry about the
syncronousRun()
and BKProc's conflict. It is now fine.

But the potential problem still exists...

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On 23.04.07 23:43:46, dukju ahn wrote:
> 2007/4/23, Andras Mantia <amantiakde.org>:
> > On Sunday 22 April 2007, dukju ahn wrote:
> > > As in my recent posts named
"SVNFileInfoProvider::status",
> > > BlockingKProcess and
KIO::NetAccess::synchronousRun()
> > > conflicts each other. This conflict happens
because each class
> > > use the same qApp->enter_loop(),
exit_loop().
> > >
> > > 1. Reasons of conflict.
> > >
> > > When CppSupportPart opens it runs
BlockingKProc::enter_loop()
> > > And the stackframe piles over that. At some
point, synchronousRun()
> > > is called on top of the stackframe.
> > > synchronousRun() also calls enter_loop(), and
the looplevel
> > > becomes three.
> > >
> > > At this point child process of BlockingProc
finishes and exit_loop()
> > > is called by the slot. This exit_loop()
causes synchronousRun()
> > > return, and the BlockingProc has no way but
to wait timeout.
> > >
> > > 2. Suggestions.
> > >
> > > It would be good if the blocking mechanism
can be implemented
> > > by different method. But if this is hard, the
BlockingKProc's timeout
> > > should be more short, because BKProc should
wait 60 seconds
> > > to exit the loop, when NetAccess::syncRun()
and BKProc conflicts,
> > >
> > > The timeout can be lowered by 3~4 seconds,
since the processes
> > > used by KDev is simple ones like "gcc -v
nullfile.cpp"
> > >
> > > Any opinions??
> >
> > BlockingKProcess uses the very same method as
NetAccess (the idea was
> > copied from there). The question is *how* can
synchronousRun be called
> > while the BlockingKProcess runs a second event
loop.
> 
> In a BKProc's second loop, events in event queue are
dispatched one by one.
> Among these, there is some event that emits signals and
subsequent slots.
> It is that slot that invokes function calls which
contains synchronousRun()

Huh? A BKProc executes and external process, why does that
trigger kio?
Or do I misunderstand something?

Andreas

-- 
Your aim is high and to the right.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Monday 23 April 2007, Andreas Pakulat wrote:
> Huh? A BKProc executes and external process, why does
that trigger
> kio? Or do I misunderstand something?

Yeah, this is unclear for me as well. 

Or do you have the following code:

some_method {
 KIO call (not via NetAccess)
 ...
 BKProcess call 
}

In this case there might be a problem as the KIO call is
actually 
performed when the event loop runs again (and this happens
in the 
BKProcess call). Such code should be avoided if possible.
But doing a 
KIO::NetAccess call followed by a BlockingKProcess call
shouldn't cause 
any problem.

Anywa, point us to the real code, so we can see it
completely.

Andras

-- 
Quanta Plus developer - http://quanta.kdewebdev.o
rg
K Desktop Environment - http://www.kde.org

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

2007/4/23, Andras Mantia <amantiakde.org>:
> On Monday 23 April 2007, Andreas Pakulat wrote:
> > Huh? A BKProc executes and external process, why
does that trigger
> > kio? Or do I misunderstand something?
>
> Yeah, this is unclear for me as well.
>
> Or do you have the following code:
>
> some_method {
>  KIO call (not via NetAccess)
>  ...
>  BKProcess call
> }
>
> In this case there might be a problem as the KIO call
is actually
> performed when the event loop runs again (and this
happens in the
> BKProcess call). Such code should be avoided if
possible. But doing a
> KIO::NetAccess call followed by a BlockingKProcess call
shouldn't cause
> any problem.

Attached file is stacktrace. At stacknumber #33,
BKProc::enter_loop()
called. In that event loop, SVNFileInfoProvider:;status() is
called, which
calls NetAccess::syncRun().
In short, syncRun()'s enter_loop() is called on the top of
the
BKProc::enter_loop().

> Anywa, point us to the real code, so we can see it
completely.

That's linenumber 80 at
http://web
svn.kde.org/branches/KDE/3.5/kdevelop/vcs/subversion/subvers
ion_fileinfo.cpp?annotate=657106

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

On Monday 23 April 2007, dukju ahn wrote:
> Attached file is stacktrace. At stacknumber #33,
BKProc::enter_loop()
> called. In that event loop,
SVNFileInfoProvider:;status() is called,
> which calls NetAccess::syncRun().
> In short, syncRun()'s enter_loop() is called on the top
of the
> BKProc::enter_loop().

Let's try to solve the problem in another way: change 
parts/fileview/fileviewpart.cpp line 72 from
QTimer::singleShot( 1000, this, SLOT(init()) );
to
QTimer::singleShot( 0, this, SLOT(init()) );

If doesn't help, replace it with a simple
init();

As I see the problem is that there is a timer running (the
one above) 
when the BKProcess code is executed, which is fired during
this 
execution of the external application in blocking mode.
Unfortunately 
this time executes code which runs KIO::NetAccess and messes
up the 
event loops. 
 Yes, this is a general problem and can happen anytime you
use 
KIO::NetAccess (and is not BKProcess specific). If you have
a timer, a 
KIO::NetAccess call, and this call takes some time and the
timer is 
fired meantime and the timer's slot executes another
KIO::NetAccess 
call, you're at the same situation.
 Using a 0 ms timer (which is anyway suggested, I have no
idea why there 
is a 1second timer there) might reduce the chance of running
in this 
bug, altough executing directly should be the safest. Other
solution 
might be to suspend existing timers, if this is possible
(e.g you know 
the pointers to the timers).

Andras

-- 
Quanta Plus developer - http://quanta.kdewebdev.o
rg
K Desktop Environment - http://www.kde.org

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel

2007/4/23, Andras Mantia <amantiakde.org>:
> On Monday 23 April 2007, dukju ahn wrote:
> > Attached file is stacktrace. At stacknumber #33,
BKProc::enter_loop()
> > called. In that event loop,
SVNFileInfoProvider:;status() is called,
> > which calls NetAccess::syncRun().
> > In short, syncRun()'s enter_loop() is called on
the top of the
> > BKProc::enter_loop().
>
> Let's try to solve the problem in another way: change
> parts/fileview/fileviewpart.cpp line 72 from
> QTimer::singleShot( 1000, this, SLOT(init()) );
> to
> QTimer::singleShot( 0, this, SLOT(init()) );
>
> If doesn't help, replace it with a simple
> init();
>
> As I see the problem is that there is a timer running
(the one above)
> when the BKProcess code is executed, which is fired
during this
> execution of the external application in blocking mode.
Unfortunately
> this time executes code which runs KIO::NetAccess and
messes up the
> event loops.

Oh.. I see. That's the reason why sometimes I encounter this
bug,
and sometimes I didn't met this bug. Actually, when I try 10
times,
one or two times run fine without bug. That depended on the
system speed, memory status and etc.

>  Yes, this is a general problem and can happen anytime
you use
> KIO::NetAccess (and is not BKProcess specific). If you
have a timer, a
> KIO::NetAccess call, and this call takes some time and
the timer is
> fired meantime and the timer's slot executes another
KIO::NetAccess
> call, you're at the same situation.
>  Using a 0 ms timer (which is anyway suggested, I have
no idea why there
> is a 1second timer there) might reduce the chance of
running in this
> bug, altough executing directly should be the safest.
Other solution
> might be to suspend existing timers, if this is
possible (e.g you know
> the pointers to the timers).

Anyway, we've removed NetAccess::synchronousRun() call by
making filetreeview ASynchronous. So there is no such bug
anymore.
But your analysis and comment will be useful for next time.

Thanks.

_______________________________________________
KDevelop-devel mailing list
KDevelop-develkdevelop.org
https://barney.cs.uni-potsdam.de/mailman/listinf
o/kdevelop-devel