https://bugs.kde.org/show_bug.cgi?id=368907
--- Comment #45 from coe...@gmail.com ---
(In reply to Mauro Carvalho Chehab from comment #43)
>
> 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.
You have an incorrect idea about the cause of this bug. Look at my demo app. I
was referring to the writeToPipe() of the demo app, not of Kaffeine, although I
named the method the same for apparent reasons. The point is that, at least on
(my) Linux, enabling a write QSocketNotifier on a FIFO is *always* wrong. It
just should not be used that way. Once enabled, Qt will start hammering the
writeToPipe() method nonstop, all the time. Note how there are never any writes
or reads on the FIFO at all in the test app. Yet the hammering goes on.
>
> 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.
The lines
if ((bytesWritten < 0) && (errno == EINTR)) {
continue;
}
are not the cause of the cpu consumption. The write is repeated *only if* the
write system call was interrupted (EINTR), but that is not what is occurring
here.
> 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().
The idea of using the read notifier is that Kaffeine writeToPipe() cannot write
to the FIFO if the VLC backend is not reading fast enough. So when
writeToPipe() cannot write all the buffers, it could enable a read notifier.
Once the VLC backend reads, Qt will emit the read signal and writeToPipe()
could resume writing the rest of the buffers.
But again, the write notifier does not work correctly on FIFOs and cannot be
the right way to do this.
--
You are receiving this mail because:
You are watching all bug changes.
