[Gambas-user] something's broken (do not know what)
g4mba5 at gmail.com
Wed Jul 14 01:16:56 CEST 2021
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...
> 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.
More information about the User