Re: Performance degradation in commit ac1d794

Поиск
Список
Период
Сортировка
От Andres Freund
Тема Re: Performance degradation in commit ac1d794
Дата
Msg-id 20160114172216.GL10941@awork2.anarazel.de
обсуждение исходный текст
Ответ на Re: Performance degradation in commit ac1d794  (Andres Freund <andres@anarazel.de>)
Ответы Re: Performance degradation in commit ac1d794  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: Andres Freund
Дата:
Сообщение: Re: Performance degradation in commit ac1d794
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Performance degradation in commit ac1d794