https://bugs.kde.org/show_bug.cgi?id=368907
--- Comment #43 from Mauro Carvalho Chehab <mchehab+...@kernel.org> ---
(In reply to coekbe from comment #41)
> Created attachment 106508 [details]
> Demo app to show infinite signal emission
>
> It looks like using a write notifier on a FIFO (or an ordinary file) is
> invalid. I attached a small application to demonstrate this. After unzipping
> and changing to the directory, try it with:
>
> qmake -project
> qmake
> make
> mkfifo testpipe
> ./testapp
>
> On my system, writeToPipe() will be called on and on and starting
> immediately even though there is nothing going on at the fifo.
That's the expected behavior. Basically, reads and writes are buffered
internally at the Kernel. When such buffer is filled, a write to the
buffer will return an error code, if the file descriptor is opened in
non-blocking mode, until the buffer is flushed. So, if you do something
like (with is what the writeToPipe loop actually does):
while (write(fd, data, size) < 0) {}
it will call write() several times, spending a lot of CPU cycles doing nothing.
the usage of a QSocketNotifier there is meant to avoid doing that.
Basically, if write() returns an error (typically, EAGAIN), indicating
that the Kernel buffer is full, the routine will exit and called later,
when the buffer is flushed.
That should save some CPU load during normal Kaffeine operation.
> On the other
> hand, (if the app is modified accordingly) as a read notifier it appears to
> work as expected even on FIFOs. Perhaps the notifier should be on reading
> instead?
A read notifier doesn't make much sense with the current code. Take a look at
processData(): basically, when some data is received, it updates the buffer,
then it calls writeToPipe().
--
You are receiving this mail because:
You are watching all bug changes.
