Skip site navigation (1) Skip section navigation (2)

Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)

From: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>
To: Fujii Masao <masao(dot)fujii(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)
Date: 2010-08-27 08:15:28
Message-ID: 4C777420.9000909@enterprisedb.com (view raw or flat)
Thread:
Lists: pgsql-hackers
On 27/08/10 10:39, Fujii Masao wrote:
> On Thu, Aug 26, 2010 at 7:40 PM, Heikki Linnakangas
> <heikki(dot)linnakangas(at)enterprisedb(dot)com>  wrote:
>> There's two kinds of latches, local and global. Local latches can only be
>> set from the same process - allowing you to replace pg_usleep() with
>> something that is always interruptible by signals (by setting the latch in
>> the signal handler). The global latches work the same, and indeed the
>> implementation is the same, but the latch resides in shared memory, and can
>> be set by any process attached to shared memory. On Unix, when you set a
>> latch waited for by another process, the setter sends SIGUSR1 to the waiting
>> process, and the signal handler sends the byte to the self-pipe to wake up
>> the select().
>
> According to this explanation, the latch which walsender uses seems to be
> local. If it's true, walsender should call InitSharedLatch rather than
> InitLatch?

Yes, it should.

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

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2010-08-27 11:49:15
Subject: Re: refactoring comment.c
Previous:From: Fujii MasaoDate: 2010-08-27 07:39:14
Subject: Re: Interruptible sleeps (was Re: CommitFest 2009-07: Yay, Kevin! Thanks, reviewers!)

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group