On 31/08/10 15:47, Fujii Masao wrote:
> On Fri, Aug 27, 2010 at 4:39 PM, Fujii Masao<masao(dot)fujii(at)gmail(dot)com>  wrote:
>>> /*
>>>   * XXX: Should we invent an API to wait for data coming from the
>>>   * client connection too? It's not critical, but we could then
>>>   * eliminate the timeout altogether and go to sleep for good.
>>>   */
>>
>> Yes, it would be very helpful when walsender waits for the ACK from
>> the standby in upcoming synchronous replication.
>
> I propose to change WaitLatch() so that it accepts the socket
> descriptor as an argument, to wait for data coming from the
> client connection.

Yeah, we probably should do that now.

>  WaitLatch() monitors not only the self-pipe
> but also the given socket. If -1 is supplied, it checks only
> the self-pipe.

The obvious next question is how to wait for multiple sockets and a 
latch at the same time? Perhaps we should have a select()-like interface 
where you can pass multiple file descriptors. Then again, looking at the 
current callers of select() in the backend, apart from postmaster they 
all wait for only one fd.

> The socket should be monitored by using poll() if the platform
> has it, since poll() is usually more efficient.

Yeah, I guess.

> So I'd like to change Unix implementation of WaitLatch() as
> follows. Thought?
>
> -------------------
> define WaitLatch(latch, timeout) WaitLatchAndSocket(latch, -1, timeout)
>
> void WaitLatchAndSocket(Latch *latch, int sock, long timeout);
> {
>      ...
>
>      FD_SET(selfpipe_readfd,&input_mask);
>      if (sock != -1)
>          FD_SET(sock,&input_mask);
>
> #ifdef HAVE_POLL
>      poll(...)
> #else
>      select(...)
>   #endif   /* HAVE_POLL */
>
>      ...
> }
> -------------------

Yep.

> Windows implementation of WaitLatchAndSocket() seems not to be
> so simple. We would need to wait for both the latch event and
> the packet from the socket by using WaitForMultipleObjectsEx().

Well, we already use WaitForMultipleObjectsEx() to implement select() on 
Windows, so it should be straightforward to copy that. I'll look into that.

-- 
   Heikki Linnakangas
   EnterpriseDB   http://www.enterprisedb.com

In response to

• Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!) at 2010-08-31 12:47:51 from Fujii Masao

Responses

• Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!) at 2010-09-02 03:46:16 from Fujii Masao

pgsql-hackers by date

Next:	From: Pavel Stehule	Date: 2010-09-01 07:30:08
	Subject: Re: array_agg() NULL Handling
Previous:	From: David E. Wheeler	Date: 2010-09-01 07:03:41
	Subject: Re: array_agg() NULL Handling