On 31/08/10 15:47, Fujii Masao wrote:
On Fri, Aug 27, 2010 at 4:39 PM, Fujii Masao<masao.fu...@gmail.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

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Reply via email to