Re: [PATCH] /dev/epoll update ...

[Christopher K. St. John]

Davide Libenzi wrote:
> 
> >     - check new_socket_fd for readable, writable, and
> >       error. if any true, then add new event to
> >       event queue, as if the state had changed.
> 
> No it does't check. It's not needed for how it works.
> 

 Yes, I see that it currently works that way. I'm
suggesting that it's a needlessly awkward way to work.
It also results in thousands of spurious syscalls a
second as servers are forced to double check there
isn't i/o to be done.

 This is frustrating, as the application must ask for
information that the kernel could have easily provided
in the first place.

 Providing an initial set of events makes application
programming easier, doesn't appear to add significant
complexity to the driver (maybe), greatly reduces the
number of required system calls, and still fits neatly
into the conceptual api model. It seems like a clear
win.

> I intentionally changed the name to epoll because it
> works in a different way.
>

 Am I missing something? I don't think you'd need a
linear scan of anything, and there wouldn't be any
changes to the api. Existing code would work exactly
the same. Etc.

 It's Davide's patch, and if he doesn't like my
suggestion, I certainly don't expect him to change his
code. If there's any consensus that the "initial event
set" behavior is a good thing, I'd be willing to whip
up a patch to Davide's patch. OTOH, if there's a good
reason the changes are a bad thing, I don't want to
confuse the issue with yet-another /dev/poll variant.

 Does anybody else have an opinion?

-- 
Christopher St. John [e-mail]
DistribuTopia http://www.distributopia.com