On Thu, 01/08 17:28, Andy Lutomirski wrote: > On Thu, Jan 8, 2015 at 5:25 PM, Fam Zheng <famz@xxxxxxxxxx> wrote: > > On Thu, 01/08 09:57, Andy Lutomirski wrote: > >> I'd like to see a more ambitious change, since the timer isn't the > >> only problem like this. Specifically, I'd like a syscall that does a > >> list of epoll-related things and then waits. The list of things could > >> include, at least: > >> > >> - EPOLL_CTL_MOD actions: level-triggered epoll users are likely to > >> want to turn on and off their requests for events on a somewhat > >> regular basis. > > > > This sounds good to me. > > > >> > >> - timerfd_settime actions: this allows a single syscall to wait and > >> adjust *both* monotonic and real-time wakeups. > > > > I'm not sure, doesn't this break orthogonality between epoll and timerfd? > > Yes. It's not very elegant, and more elegant ideas are welcome. What is the purpose of embedding timerfd operation here? Modifying timerfd for each poll doesn't sound a common pattern to me. > > > > >> > >> Would this make sense? It could look like: > >> > >> int epoll_mod_and_pwait(int epfd, > >> struct epoll_event *events, int maxevents, > >> struct epoll_command *commands, int ncommands, > >> const sigset_t *sigmask); > > > > What about flags? > > > > No room. Maybe it should just be a struct for everything instead of > separate args. Also no room for timeout. A single struct sounds the only way to go. Fam -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
