Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)

From: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
To: Larry Rosenman <ler(at)lerctr(dot)org>
Cc: pgsql-hackers(at)postgresql(dot)org
Subject: Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
Date: 2000-11-16 20:27:29
Message-ID: 200011162027.PAA28316@candle.pha.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

> * Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> [001116 14:02]:
> > > > This sounds like an interesting approach, yes.
> > > Question: Is sleep(0) guaranteed to at least give up control?
> > >
> > > The way I read my UnixWare 7's man page, it might not, since alarm(0)
> > > just cancels the alarm...
> >
> > Well, it certainly is a kernel call, and most OS's re-evaluate on kernel
> > call return.
> BUT, do we know for sure that sleep(0) is not optimized in the library
> to just return?

We can only do our best here. I think guessing whether other backends
are _about_ to commit is pretty shaky, and sleeping every time is a
waste. This seems the cleanest.

Funny you should mention the optimization. I just checked BSDI and saw:

u_int
sleep(secs)
u_int secs;
{
struct timeval nt, ot;
long diff;
int rc;

if (secs == 0)
return (0);

So maybe we need another _fake_ kernel call, or a select/usleep with a
very small value.

--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Peter Eisentraut 2000-11-16 20:57:57 Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)
Previous Message Alfred Perlstein 2000-11-16 20:12:58 Re: RE: [COMMITTERS] pgsql/src/backend/access/transam ( xact.c xlog.c)