On Wed, Mar 16, 2016 at 2:52 PM, Andres Freund <and...@anarazel.de> wrote: > How about the following sketch of an API > > typedef struct LatchEvent > { > uint32 events; /* interesting events */ > uint32 revents; /* returned events */ > int fd; /* fd associated with event */ > } LatchEvent; > > typedef struct LatchEventSet > { > int nevents; > LatchEvent events[FLEXIBLE_ARRAY_MEMBER]; > } LatchEventSet; > > /* > * Create a LatchEventSet with space for nevents different events to wait for. > * > * latch may be NULL. > */ > extern LatchEventSet *CreateLatchEventSet(int nevents, Latch *latch);
We might be able to rejigger this so that it didn't require palloc, if we got rid of FLEXIBLE_ARRAY_MEMBER and passed int nevents and LatchEvent * separately to WaitLatchThingy(). But I guess maybe this will be infrequent enough not to matter. > I've two questions: > - Is there any benefit of being able to wait for more than one latch? > I'm inclined to not allow that for now, that'd make the patch bigger, > and I don't see a use-case right now. I don't see a use case, either. > - 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. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers