Date: Sat, 11 Sep 2021 14:13:37 UTC
On Sat, Sep 11, 2021 at 11:15:12AM +0300, Andriy Gapon wrote: > On 10/09/2021 22:40, Andriy Gapon wrote: > > On 10/09/2021 22:38, Andriy Gapon wrote: > >> On 10/09/2021 22:35, Mark Johnston wrote: > >>> Indeed, I suspect that this is the problem. Note that for > >>> kevent(EVFILT_READ) we subtract the number of control message bytes from > >>> the returned value, see filt_soread(). I wonder if FIONREAD should do > >>> the same thing. > >> > >> Thank you for the suggestion. > >> I think that it is a reasonable expectation that FIONREAD returns a number of > >> bytes that can be actually read. > >> I'll look at filt_soread(). > > > > kn_data = sbavail(&so->so_rcv) - so->so_rcv.sb_ctl; > > Is this it? > > Looks simple enough for a quick test :) > > > Works perfectly. > Should I just commit it or is a larger discussion needed? I think the semantic change is ok. Did you change FIONREAD to lock the sockbuf? I think it would be necessary to avoid races with pulseaudio: sb_acc is modified before sb_ctl, so there could be windows where sbavail(sb) - sb->sb_ctl gives a larger. And, it is not really safe to lock the sockbuf itself, since it may be overwritten by a listen(2) call. SOCK_RECVBUF_LOCK(so) should be used instead.