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.
The Enterprise PostgreSQL Company
Sent via pgsql-hackers mailing list (firstname.lastname@example.org)
To make changes to your subscription: