pa_fdsem racy?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [Linux Audio Users]     [AMD Graphics]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux