[pulseaudio-discuss] pa_fdsem racy?
Daniel Mack
daniel at caiaq.de
Tue Dec 1 05:15:02 PST 2009
On Tue, Dec 01, 2009 at 01:34:11PM +0100, Daniel Mack wrote:
> I suspect this implementation to be racy, but I might have not
> understood the sematic of this data type. Is a pa_fdsem supposed to be
> accessed by more than one reader/writer? I wrote a little test which
> shows that the latter does not work reliably:
One more thing that caught my eye and which doesn't seem to make
terribly much sense to me is code in flush() and pa_fdsem_wait()
from pulsecore/fdsem.c. There are snipplets that read as follows
for !HAVE_SYS_EVENTFD_H:
do {
char x[10];
// HAVE_SYS_EVENTFD_H code omitted
if ((r = read(f->fds[0], &x, sizeof(x))) <= 0) {
pa_assert(r < 0 && errno == EINTR);
continue;
}
} while (pa_atomic_sub(&f->data->in_pipe, (int) r) > (int) r);
A read() of 10 bytes from a pipe will _block_ until at least 10 bytes
have been written to the counterpart fd. Why is that 10, where does the
magic come from? How is that supposed to work for occasions of writes
that are not muliples of 10 bytes? I'm confused.
Daniel
More information about the pulseaudio-discuss
mailing list