Re: KQueue 0-length UDP packet

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 comment on this? Is it a bug?

----------------------

Regarding OSX:

Submitted Apple Bug # 17894467 , with a patch.

If anyone has friends at Apple who could help getting this in, please let
me know!

Cheers,
Fedor.


On Sat, Aug 2, 2014 at 2:41 PM, Fedor Indutny <fedor_at_indutny.com> wrote:

> 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 <fedor_at_indutny.com> wrote:
>
>> 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 FreeBSD and OSX are treating NOTE_LOWAT
>> differently:
>>
>> *
>> https://github.com/opensource-apple/xnu/blob/2fa84067f6cdeb23267f877ca4fd26201316da1b/bsd/kern/uipc_socket.c#L4461
>> *
>> https://github.com/freebsd/freebsd/blob/6901832d8588537c81afbdb91d1a22deb5582c47/sys/kern/uipc_socket.c#L3163-L3164
>>
>> FreeBSD's NOTE_LOWAT is overriding SO_RCVLOWAT, and OSX is using
>> SO_RVCLOWAT as a minimum value. But, since NOTE_LOWAT is not
>> involved here by default, I'm failing to see where exactly this
>> event could pass through kqueue filter.
>>
>> Could anyone with UDP and/or KQueue implementation knowledge
>> share some insights with me?
>>
>> Thank you very much!
>> Fedor.
>>
>> (NOTE: Duplicate, first email wasn't posted, because I wasn't subscribed
>> to the ML)
>>
>
>