On 2016-03-16 15:41:28 -0400, Robert Haas wrote:
> On Wed, Mar 16, 2016 at 3:25 PM, Andres Freund <andres@anarazel.de> wrote:
> >> > - Given current users we don't need a large amount of events, so having
> >> > to iterate through the registered events doesn't seem bothersome. We
> >> > could however change the api to be something like
> >> >
> >> > int WaitLatchEventSet(LatchEventSet *set, OccurredEvents *, int nevents, long timeout);
> >> >
> >> > which would return the number of events that happened, and would
> >> > basically "fill" one of the (usually stack allocated) OccurredEvent
> >> > structures with what happened.
> >>
> >> I definitely think something along these lines is useful. I want to
> >> be able to have an Append node with 100 ForeignScans under it and kick
> >> off all the scans asynchronously and wait for all of the FDs at once.
> >
> > So you'd like to get only an event for the FD with data back? Or are you
> > ok with iterating through hundred elements in an array, to see which are
> > ready?
>
> I'd like to get an event back for the FD with data. Iterating sounds
> like it could be really slow. Say you get lots of little packets back
> from the same connection, while the others are idle. Now you've got
> to keep iterating through them all over and over again. Blech.
Well, that's what poll() and select() require you to do internally
anyway, even if we abstract it away. But most platforms have better
implementations (epoll, kqueue, ...), so it seems fair to design for
those.
Andres