On Fri, 13.12.13 13:08, Shawn Landden (sh...@churchofgit.com) wrote: > If this event is not the highest priority, then it will not be > dispatched when the epoll triggers, and since we will not get any more > wakeups (due to the way EPOLLONESHOT works) will never be dispatched.
Hmm, so the way this is supposed to work is that as soon as epoll told us about some event once, we will set the event source to "pending", and it stays "pending" until we have dispatched it, regardless if we ever get the event from epoll again or not. However, we currently will overwrite the "revents" field should we ever get it again with the new one. It probably makes more sense to OR it in, so that we don't forget readability if writability happens at a later point or vice versa, if you follow what I mean. I'll prep a fix for that. With that fixed is there something else to still fix? > Since we only handle one event per epoll_wait() wakeup, > and we dequeue a ONE_SHOT event when we dispatch it, we > do not have the problem described in epoll(7) of > "multiple events can be generated upon receipt of multiple > chunks of data". Not sure I follow here? That part appears to be about EPOLLET? Lennart -- Lennart Poettering, Red Hat _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
