[Gambas-user] something's broken (do not know what)

[Benoît Minisini]

Le 14/07/2021 à 00:10, Bruce Steers a écrit :
> 
> 
> On Tue, 13 Jul 2021, 22:13 Benoît Minisini, <g4mba5 at gmail.com 
> <mailto:g4mba5 at gmail.com>> wrote:
> 
>     Le 13/07/2021 à 15:57, Bruce Steers a écrit :
>      >
>      > Right this bug fixed on LinuxMint but on Debian11 i'm getting it
>     and i
>      > cannot fix it.
>      > i used your gdb command and got this text...
>      >
>      > I hope it means more to you than it does to me.
>      >
>      > bonus at debian:/mnt/SSDiskspace/git/scripted-oldgambas$
>     GB_GUI=gb.gtk3 gdb
>      > gbx3
>       > [...]
> 
>     Thanks, it is looping forever where it should, or (better) where it
>     should not: searching for a default control to focus.
> 
>     I have no idea why I can't reproduce the problem. Maybe you didn't tell
>     me exactly what you did.
> 
>     Otherwise, there is another bug in GTK+3 that makes your program eat
>     100% CPU: opeing a pipe for watching. For an unknown reason to me, the
>     GTK+3 event loop is woken up permanently when it watches the pipe file
>     descriptor (but not the QT event loop).
> 
>     By the way, I don't know why you implemented this pipe thing. You are
>     reinventing DBus actually.
> 
> 
> Aah I'll look into that, any pipe stuff is residual from me recently 
> changing to dbus (only did that the other day) using a pipe was how I 
> first did it. I'll remove it. I pushed the changes to fix the git repo 
> yesterday but it wasn't really ready.
> Will be nice if it's the pipe causing the trouble. Will be home in an 
> hour to test.
> 
> Thanks for looking into it.
> 
> Odd though how it's now fixed in mint.
> Deb 11 now has bug but not if I revert that commit i mentioned. Bug goes 
> away without those changes?
> 
> Respects
> BruceS
> 

This is not directly the pipe the problem, but the `Shell "echo '' > 
..."` command that you issue to prevent possible blocking on pipe open.

If I remove that line, the GTK+ event loop now blocks normally, and does 
not eat CPU anymore.

That's strange: if I keep the Shell command, then there is something to 
read on the pipe, so the "File_Read" event is raised, the data is read, 
and so there is nothing left inside the pipe, the pipe is not ready to 
be read anymore, and no event is raised.

So why then does it make the GTK+ event loop wake up repeatedly (without 
telling me that the pipe is ready to read)?

It actually woke up because of an internal timeout parameter (which is 
normally associated with the earlier timer to be raised) very low. If I 
remove the Shell initial command, that timeout has the expected value 
(which correspond to the blinking editor cursor).

I will try to run a little program with just the pipe...

Regards,

-- 
Benoît Minisini