On 2016-03-18 14:00:58 -0400, Robert Haas wrote: > No, I mean it should be quite common for a particular fd to have no > events reported. If we're polling on 100 fds and 1 of them is active > and the other 99 are just sitting there, we want to skip over the > other 99 as quickly as possible.
cur_events points to the event that's registered with the set, not the one that's "returned" or "modified" by poll/select, that's where the confusion is originating from. I'll add a fastpath. Greetings, Andres Freund -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
