On 10.05.2011 11:22, Peter Geoghegan wrote:
On 10 May 2011 02:58, Fujii Masao<masao.fu...@gmail.com> wrote:
Alright. I'm currently working on a proof-of-concept implementation of
that. In the meantime, any thoughts on how this should meld with the
existing latch implementation?
How about making WaitLatch monitor the file descriptor for the pipe
by using select()?
Alright, so it's reasonable to assume that all clients of the latch
code are happy to be invariably woken up on Postmaster death?
That doesn't sound like a safe assumption. All the helper processes
should die quickly on postmaster death, but I'm not sure if that holds
for all inter-process communication. I think the caller needs to specify
if he wants that or not.
Once you add that to the WaitLatchOrSocket function, it's quite clear
that the API is getting out of hand. There's five different events that
can wake it up:
* latch is set
* a socket becomes readable
* a socket becomes writeable
* timeout
* postmaster dies
I think we need to refactor the function into something like:
#define WL_LATCH_SET 1
#define WL_SOCKET_READABLE 2
#define WL_SOCKET_WRITEABLE 4
#define WL_TIMEOUT 8
#define WL_POSTMASTER_DEATH 16
int WaitLatch(Latch latch, int events, long timeout)
Where 'event's is a bitmask of events that should cause a wakeup, and
return value is a bitmask identifying which event(s) caused the call to
return.
--
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
