Re: Performance degradation in commit ac1d794 - Mailing list pgsql-hackers
From | Andres Freund |
---|---|
Subject | Re: Performance degradation in commit ac1d794 |
Date | |
Msg-id | 20160316185210.d3lymbovlch4htaw@alap3.anarazel.de Whole thread Raw |
In response to | Re: Performance degradation in commit ac1d794 (Robert Haas <robertmhaas@gmail.com>) |
Responses |
Re: Performance degradation in commit ac1d794
|
List | pgsql-hackers |
On 2016-01-14 12:07:23 -0500, Robert Haas wrote: > On Thu, Jan 14, 2016 at 12:06 PM, Andres Freund <andres@anarazel.de> wrote: > > On 2016-01-14 11:31:03 -0500, Robert Haas wrote: > >> On Thu, Jan 14, 2016 at 10:56 AM, Andres Freund <andres@anarazel.de> wrote: > >> I think your idea of a data structure the encapsulates a set of events > >> for which to wait is probably a good one. WaitLatch doesn't seem like > >> a great name. Maybe WaitEventSet, and then we can have > >> WaitLatch(&latch) and WaitEvents(&eventset). > > > > Hm, I'd like to have latch in the name. It seems far from improbably to > > have another wait data structure. LatchEventSet maybe? The wait would be > > implied by WaitLatch. > > I can live with that. 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); /* ---* Add an event to the set. Possible events are:* - WL_LATCH_SET: Wait for the latch to be set* - WL_SOCKET_READABLE:Wait for socket to become readable* can be combined in one event with WL_SOCKET_WRITEABLE* - WL_SOCKET_WRITABLE:Wait for socket to become readable* can be combined with WL_SOCKET_READABLE* - WL_POSTMASTER_DEATH:Wait for postmaster to die*/ extern void AddLatchEventToSet(LatchEventSet *set, uint32 events, int fd); /** Wait for any events added to the set to happen, or until the timeout is* reached.** The return value is the union ofall the events that were detected. This* allows to avoid having to look into the associated events[i].revents* fields.*/ extern uint32 WaitLatchEventSet(LatchEventSet *set, long timeout); 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 makethe patch bigger, and I don't see a use-case right now. - Given current users we don't need a large amount of events, so having to iterate through the registered events doesn'tseem 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) OccurredEventstructures with what happened. Comments?
pgsql-hackers by date: