Jason Baron writes:
> On 10/02/2015 03:30 PM, Rainer Weikusat wrote:
>> Jason Baron writes:
>>> From: Jason Baron
>>>
>>> The unix_dgram_poll() routine calls sock_poll_wait() not only for the wait
>>> queue associated with the socket s that we've called poll() on, but it also
>>> calls sock_poll
Rainer Weikusat writes:
> Jason Baron writes:
>> From: Jason Baron
>>
>> The unix_dgram_poll() routine calls sock_poll_wait() not only for the wait
>> queue associated with the socket s that we've called poll() on, but it also
>> calls sock_poll_wait() for a remote peer socket's wait queue, if i
On 10/02/2015 03:30 PM, Rainer Weikusat wrote:
> Jason Baron writes:
>> From: Jason Baron
>>
>> The unix_dgram_poll() routine calls sock_poll_wait() not only for the wait
>> queue associated with the socket s that we've called poll() on, but it also
>> calls sock_poll_wait() for a remote peer soc
Jason Baron writes:
> From: Jason Baron
>
> The unix_dgram_poll() routine calls sock_poll_wait() not only for the wait
> queue associated with the socket s that we've called poll() on, but it also
> calls sock_poll_wait() for a remote peer socket's wait queue, if it's
> connected.
> Thus, if we
From: Jason Baron
The unix_dgram_poll() routine calls sock_poll_wait() not only for the wait
queue associated with the socket s that we've called poll() on, but it also
calls sock_poll_wait() for a remote peer socket's wait queue, if it's connected.
Thus, if we call poll()/select()/epoll() for th