On 1/26/18 12:18 PM, Pradeep wrote:
In svc_vc_recv(), we handle the case of incomplete receive by rearming the FD and returning ( if xd->sx_fbtbc is not zero). In the case of EAGAIN also shouldn't we be doing the same? epoll is ONESHOT; so new receives won't give new events until epoll_ctl()
is c
Branch next
Tag:V2.6-rc4
NOTE: This merge has an ntirpc pullup. Please updste your submodule.
Release Highlights
* ntirpc pullup
* CI tests
* LLT trace points
* Fix new warnings from GCC 7.2
* Clean up compounds from V4.1 slot cache om ending session
Signed-off-by: Frank S. Filz
Contents
Hi Dan,
In svc_vc_recv(), we handle the case of incomplete receive by rearming the
FD and returning ( if xd->sx_fbtbc is not zero). In the case of EAGAIN also
shouldn't we be doing the same? epoll is ONESHOT; so new receives won't
give new events until epoll_ctl() is called, right?
I tried adding
Yes, I wasn't claiming there is anything missing. Before 2.6, there
was a rearm method being called.
Matt
On Fri, Jan 26, 2018 at 9:20 AM, Daniel Gryniewicz wrote:
> I don't think you re-arm a FD in epoll. You arm it once, and it fires until
> you disarm it, as far as I know. You just call ep
I don't think you re-arm a FD in epoll. You arm it once, and it fires
until you disarm it, as far as I know. You just call epoll_wait() to
get new events.
The thread model is a bit odd; When the epoll fires, all the events are
found, and a thread is submitted for each one except one. That
>From Daniel Gryniewicz :
Daniel Gryniewicz has uploaded this change for review. (
https://review.gerrithub.io/396615
Change subject: pullup ntirpc: client error fixes
..
pullup ntirpc: client error fixes
Change-Id: I32875c73