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

[Bruce Steers]

On Wed, 14 Jul 2021 at 00:17, Benoît Minisini <g4mba5 at gmail.com> wrote:

> Le 14/07/2021 à 00:47, Benoît Minisini a écrit :
> > Le 14/07/2021 à 00:36, Benoît Minisini a écrit :
> >>
> >> 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,
> >>
> >
> > Same behaviour: reading the pipe ready to read make the GTK+ event loop
> > wake up repeatedly even if there is nothing to read anymore on the pipe.
> >
>
> OK, this is apparently not a bug, but a feature.
>
> As you open the pipe for read, as soon as you write something on the
> other side of the pipe, and then terminates (with "echo" for example),
> Linux starts to wake up the process with repeated "POLLHUP" events to
> tell you that there is no writer on the pipe anymore, until a new
> process starts to write to the pipe again.
>
> BUT it does not raise these events when you open the pipe alone the
> first time. Not very logical.
>
> I don't know how QT prevented that behaviour. It seems that GTK+ always
> ask Linux to send these POLLHUP events, even if you specified you are
> not interested by them.
>
> The only reasonable solution is apparently opening the pipe both for
> reading and writing, so that there is always at least one writer
> process. In that case, the "POLLHUP" events are not sent.
>

after getting home i looked for the residual pipe code and realised I had
removed it all and you must be using the scripted-newgambas version.
I have not worked on that version for some time. after making the html
previewer using the gtk webview i then realised that wouldn't work on older
gambas versions so the program diverged into 2 branches the oldgambas
version i changed to use a gbs script to open a separate qt form that uses
a pipe to move/size with the main window (terribly lol)
and have continued to develop the oldgambas version and not done much to
the other.

so, confusingly, the oldgambas version (the default branch) has been
further developed (in many areas) than the newgambas version.

and i will remove the pipe functions completely from the startup and use
dbus (like i have in the oldgambas version)
and see if read-write works on pipes i use.

Thank you.
BruceS
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/user/attachments/20210714/18e4fcb9/attachment.htm>