Ok, thanks for a clarification!
On Tue, Aug 26, 2014 at 1:48 PM, Jan Kokemüller
wrote:
> Hi,
>
>
> What I wanted to ask is: why does FreeBSD kqueue implementation treat
>> `SO_RCVLOWAT` as a raw packet size watermark, and not using the actual
>> data size for filtering out events?
>>
>
> It lo
Hi,
What I wanted to ask is: why does FreeBSD kqueue implementation treat
`SO_RCVLOWAT` as a raw packet size watermark, and not using the actual
data size for filtering out events?
It looks like SO_RCVLOWAT refers to the number of bytes in the socket
buffer, not raw packet bytes. In the case
Hello again!
I just realized that the wording was probably a bit off.
What I wanted to ask is: why does FreeBSD kqueue implementation treat
`SO_RCVLOWAT` as a raw packet size watermark, and not using the actual
data size for filtering out events?
I am totally fine with the fact that it triggers
After reading that line more carefully, I wonder if this behavior is really
intentional here.
It seems to me that `SO_RCVLOWAT` is supposed to set watermark value in
terms of
packet data bytes, not just raw packet size. And this is how `NOTE_LOWAT`
actually
works there, right?
Could anyone please
Guess I know the answer:
https://cloudup.com/cCkjLhI4M2r
Basically, OSX is checking `kn_data` and FreeBSD is using
`so->so_rcv.sb_cc`.
Thank you anyway!
On Sat, Aug 2, 2014 at 1:39 PM, Fedor Indutny wrote:
> Hello!
>
> I'm trying to figure out, why this code:
>
> https://github.com/indutny/0
Hello!
I'm trying to figure out, why this code:
https://github.com/indutny/0-udp
Which basically sends a 0-length UDP packet to a server and polls
kqueue events on the server fd.
Return 1 kevent on FreeBSD, and blocks indefinitely without
returning any events on OSX.
So far I could see that Fr
