Re: Performance degradation in commit ac1d794 - Mailing list pgsql-hackers

From Andres Freund
Subject Re: Performance degradation in commit ac1d794
Date
Msg-id 20160114172216.GL10941@awork2.anarazel.de
Whole thread Raw
In response to Re: Performance degradation in commit ac1d794  (Andres Freund <andres@anarazel.de>)
Responses Re: Performance degradation in commit ac1d794  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On 2016-01-14 18:14:21 +0100, Andres Freund wrote:
> I'm thinking of something like;
> 
> int WaitOnLatchSet(LatchEventSet *set, int wakeEvents, long timeout);
> 
> int
> WaitLatchOrSocket(volatile Latch *latch, int wakeEvents, pgsocket sock,long timeout)
> {
>         LatchEventSet set;
> 
>         LatchEventSetInit(&set, latch);
> 
>         if (sock != PGINVALID_SOCKET)
>            LatchEventSetAddSock(&set, sock);
> 
>         return WaitOnLatchSet(set, wakeEvents, timeout);
> }
> 
> I think we'll need to continue having wakeEvents and timeout parameters
> for WaitOnLatchSet, we quite frequently want to wait socket
> readability/writability, not wait on the socket, or have/not have
> timeouts.

This brings me to something related: I'm wondering if we shouldn't merge
unix/win32_latch.c. If we go this route it seems like the amount of
shared infrastructure will further increase. The difference between
win32 and, say, the select code isn't much bigger than the difference
between select/poll. epoll/win32 are probably more similar than that
actually.

Andres



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: Performance degradation in commit ac1d794
Next
From: Tom Lane
Date:
Subject: Re: Performance degradation in commit ac1d794