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

Benoît Minisini 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...
>>
>> 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.

Regards,

-- 
Benoît Minisini


More information about the User mailing list